#oop

객체지향 언어가 제공하는 업캐스팅과 동적 바인딩을 이용하면 부모 클래스 참조에 대한 메시지 전송을 자식 클래스에 대한 메서드 호출로 변환할 수 있다. 객체지향 시스템은 다음 규칙에 따라 실행할 메서드를 선택한다. 메시지를 수신한 객체는 먼저 자신을 생성한 클래스에 적합한 메서드가 존재하는지 검사하낟. 존재하면 메서드를 실행하고 탐색을 종료한다. 메서드를 찾지 못했다면 부모 클래스에서 메서드 탐색을 계속 한다. 이 과정은 적합한 메서드를 찾을 때 까지 상속 계층을 따라 올라가며 계속된다. 상속 계층의 가장 최상위 클래스에 이르렀지만

퍼블릭 인터페이스에 오퍼레이션을 정의할때 참고할 수 있는 지침을 제공. 루틴 Routine : 어떤 절차를 묶어 호출 가능하도록 이름을 부여한 기능 프로시저 Procedure : 정해진 절차에 따라 내부의 상태를 변경하는 루틴의 종류. 부수효과를 발생시킴 함수 Function : 어떤 절차에 따라 필요한 값을 계산해서 반환하는 루틴의 종류. 부수효과가 없다. 명령 Command : 객체의 상태를 변경하는 명령은 반환값을 가질 수 없다. 쿼리 Query : 객체의 정보를 반환하는 쿼리는 상태를 변경할 수 없다. 질문이 답변을 수정해서

퍼블릭 인터페이스의 품질에 영향을 미치는 원칙과 기법 디미터 법칙 묻지 말고 시켜라 의도를 드러내는 인터페이스 명령-쿼리 분리 디미터 법칙 낯선 자에게 말하지 마라. 오직 인접한 이웃하고만 말하라. 오직 하나의 도트만 사용하라. 클래스 내부의 메서드가 아래 조건을 만족하는 인스턴스에만 메시지를 전송하도록 프로그래밍해야 한다. this 객체 메서드의 매개변수 this의 속성 this의 속성인 컬렉션의 요소 메서드 내에서 생성된 지역 객체 부끄럼타는 코드 Shy code : 불필요한 어떤 것도 다른 객체에게 보여주지 않으며, 다른 객체

객체지향 프로그래밍에서 어플리케이션이 클래스의 집합으로 구성된다는것은 오해다. 클래스라는 구현 도구에 지나치게 집착하면 경직되고 유연하지 못한 설계에 이를 수 있다. 좋은 객체지향 코드를 얻기 위해서 클래스가 아닌 객체를 지향해야 한다. 이는 곧 협력 안에서 객체가 수행하는 책임에 초점을 맞춰야 한다. 책임은 객체가 수신할 수 있는 메시지의 기반이 된다. 메시지는 객체 사이의 협력을 가능하게 하는 매개체다. 객체가 다른 객체에게 접근할 수 있는 유일한 방법은 메시지를 전송하는 것뿐이다. 협력 안에서 메시지를 전송하는 객체를 클라이언

메시지를 처리할 책임과 책임을 수행하는데 필요한 변수 지정을 먼저 한다. 다른 객체의 구현을 고려할 필요 없이 필요한 메시지를 결정하면 다른 객체의 내부 구현을 깔끔하게 캡슐화 할 수 있다. 메시지가 변경되지 않는 한 객체에 어떤 수정을 가하더라도 호출하는 쪽에는 영향을 미치지 않는다. 메시지를 기반으로 협력을 구성하면 객체 사이 결합도를 느슨하게 유지할 수 있다. 책임 주도 설계 calculateFee()를 위한 객체 설계를 한다. 상세 구현을 한다. 4장과 다른점은 switch 문 내에 또 다른 분기가 없다는 점 정도.. 첫번째

객체를 설계할 때 "이 객체가 어떤 데이터를 포함해야 하는가?" 라는 질문은 다음과 같은 두개의 개별적인 질문으로 분리해야 한다. 이 객체가 어떤 데이터를 포함해야 하는가? 이 객체가 데이터에 대해 수행해야 하는 오퍼레이션은 무엇인가? DiscountCondition (할인조건) 클래스에 대한 개선 Movie 클래스에 대한 개선 Screening 클래스에 대한 개선 ReservationAgency 클래스에 대한 개선 DiscountCondition 자신의 데이터를 이용해 할인 가능 여부를 스스로 판단하게 되었지만, isDiscoun

객체지향 설계의 핵심 협력 : 애플리케이션의 기능을 구현하기 위해 메시지를 주고받는 객체들 사이의 상호작용 책임 : 객체가 다른 객체와 협력하기 위해 수행하는 행동 역할 : 대체 가능한 책임의 집합 객체지향 설계 객체에 올바른 책임을 할당하면서 낮은 결합도와 높은 응집도를 가진 구조를 창조하는 활동 객체지향의 설계의 핵심은 책임이다. 책임을 할당하는 작업이 응집도와 결합도 같은 설계 품질과 깊이 연관되어 있다. 설계 설계는 변경을 위해 존재한다. 훌륭한 설계한 합리적인 비용안에서 변경을 수용할 수 있는 구조를 만드는 것이다. 변경

객체지향 패러다임 관점의 핵심 역할 Role 책임 Responsibility 협력 Collaboration 협력 : 객체들이 어플리케이션의 기능을 구현하기 위해 수행하는 상호작용 책임 : 객체가 협력에 참여하기 위해 수행하는 로직 역할 : 객체들이 협력 안에서 수행하는 책임들이 모여 객체가 수행하는 구성 객체지향 시스템은 자율적인 객체들의 공동체다. 객체는 고립된 존재가 아니라 시스템의 기능이라는 더 큰 목표를 달성하기 위해 다른 객체와 협락하는 사회적인 존재다. 협력은 객체지향 세계에서 기능을 구현할 수 있는 유일한 방법이다. 메