일종의 소프트웨어 인터페이스이며 다른 종류의 소프트웨어에 서비스를 제공한다.
이게 맞는거같음
자바,자스,파이썬,c,c++ 등등이 다 이런용도지
식당의 종업원은 너무 일부분적인거지
그럴거면 식당이라고해야지
식당이라는 api가 내부 기능들(요리사,종업원 등)을 가지고 서비스를 손님에게 제공해주는거니까
일종의 소프트웨어 인터페이스이며 다른 종류의 소프트웨어에 서비스를 제공한다.
이게 맞는거같음
자바,자스,파이썬,c,c++ 등등이 다 이런용도지
식당의 종업원은 너무 일부분적인거지
그럴거면 식당이라고해야지
식당이라는 api가 내부 기능들(요리사,종업원 등)을 가지고 서비스를 손님에게 제공해주는거니까
해당 댓글은 삭제되었습니다.
인터페이스는 맞는데 api 관점에서보면 식당이맞지 종업원이라는 api로 손님에게 제공한다. has a 관점에서봐도 식당이 서비스를 제공하는거지 종업원은 식당에 포함되어있는거고
프로그래밍 언어도 api라는 관점에서보면 이해될거임
종업원이 식당에 소속되어있다는것 has a관계라고한 것을 보면 식당이라인터페이스로 종업원클래스가 구현해야하는게 맞는게아닐까한다.
손님이라는 클래스가있고, 식당을 구현하는 종업원 클래스가있다. 그리고 손님은 식당을 has a관계로 사용하게되는것이지
api 가 인터페이스인데ㅇㅅㅇ
자료구조 관점에서부터 이야기하자면 식당이라는 인터페이스를 종업원이 구현하고, 그 식당이라는것을 손님클래스 객체가 사용하는것이다. 식당도 종류가 존나게 많을거아니냐
implement를 그냥 다른거로 지정해주면 이직하는거지 ㄷㄷ
손님 ->hasA 식당 클래스 ->hasA 종업원 인터페이스 ->isA 서빙담당,요리담당,계산담당,청소담당
주문내용생각하면 식당이라는 클래스가 필수일수밖에 없을거같긴하다
손님도 메뉴를 알아야하니까 요리내용은 public으로 한다든가
궁금한데 protect는 왜씀? 누가 누구를 상속하는거야?
손님 ->hasA 식당 클래스 ->hasA 종업원 인터페이스 ->isA 서빙담당,요리담당,계산담당,청소담당 이런구조라면 식당클래스에 메뉴를 설정하고 그 메뉴가 protected가 아니여도, 종업원이 바꿀수없을것같은데 아닌가? 식당클래스 내부 메뉴를 protected로 설정해서 사장이라는 종업원이 상속했을시에 바꾼다던가 하는것도 괜찮겠네
식당클래스 내부에는 종업원을 담는 어레이리스트도 필요하겠네
식당은 서버고 api는 주문서지 ㅇㅅㅇ
그런거 알아서 뭐하냐 대충 만들면되지
범위는 잡기 나름이지 식당이든 종업원이든
awesome pretty idol - dc Cpp
원래 비유라는건 편의성을 위해 정확성을 희생하는거기때문에 당연히 조금씩 빗나가는 점이 있음
당연히 정확하게 말하려면 그냥 정의를 그대로 말하면 되지