#협력
5
FundamentalOOP
오브젝트; 메시지와 인터페이스
객체지향 프로그래밍에서 어플리케이션이 클래스의 집합으로 구성된다는것은 오해다. 클래스라는 구현 도구에 지나치게 집착하면 경직되고 유연하지 못한 설계에 이를 수 있다. 좋은 객체지향 코드를 얻기 위해서 클래스가 아닌 객체를 지향해야 한다. 이는 곧 협력 안에서 객체가 수행하는 책임에 초점을 맞춰야 한다. 책임은 객체가 수신할 수 있는 메시지의 기반이 된다. 메시지는 객체 사이의 협력을 가능하게 하는 매개체다. 객체가 다른 객체에게 접근할 수 있는 유일한 방법은 메시지를 전송하는 것뿐이다. 협력 안에서 메시지를 전송하는 객체를 클라이언
FundamentalOOP
오브젝트; GRASP와 책임 할당하기
데이터를 먼저 결정하고 고립된 객체의 상태에 초점을 맞추면 캡슐화를 위반하기 쉽고, 요소들 사이의 결합도가 높아지며, 코드를 변경하기 어려워진다. 책임에 초점을 맞춰서 설계할 때 어떤 객체에게 어떤 책임을 할당할지를 결정 하는 것이 어렵다. 책임 할당 과정은 트레이드오프 활동이다. 데이터 중심의 설계에서 책임 중심의 설계로 전환하는 방법 클라이언트 관점에서 객체가 수행하는 행동이란 곧 객체의 책임을 의미한다. 객체는 협력에 참여하기 위해 존재하며 협렵 안에서 수행하는 책임이 객체의 존재가치를 증명한다. 너무 이른시기에 데이터에 초점
FundamentalOOP
오브젝트; 데이터 중심 설계의 문제
객체지향 설계의 핵심 협력 : 애플리케이션의 기능을 구현하기 위해 메시지를 주고받는 객체들 사이의 상호작용 책임 : 객체가 다른 객체와 협력하기 위해 수행하는 행동 역할 : 대체 가능한 책임의 집합 객체지향 설계 객체에 올바른 책임을 할당하면서 낮은 결합도와 높은 응집도를 가진 구조를 창조하는 활동 객체지향의 설계의 핵심은 책임이다. 책임을 할당하는 작업이 응집도와 결합도 같은 설계 품질과 깊이 연관되어 있다. 설계 설계는 변경을 위해 존재한다. 훌륭한 설계한 합리적인 비용안에서 변경을 수용할 수 있는 구조를 만드는 것이다. 변경
FundamentalOOP
오브젝트; 역할, 책임, 협력
객체지향 패러다임 관점의 핵심 역할 Role 책임 Responsibility 협력 Collaboration 협력 : 객체들이 어플리케이션의 기능을 구현하기 위해 수행하는 상호작용 책임 : 객체가 협력에 참여하기 위해 수행하는 로직 역할 : 객체들이 협력 안에서 수행하는 책임들이 모여 객체가 수행하는 구성 객체지향 시스템은 자율적인 객체들의 공동체다. 객체는 고립된 존재가 아니라 시스템의 기능이라는 더 큰 목표를 달성하기 위해 다른 객체와 협락하는 사회적인 존재다. 협력은 객체지향 세계에서 기능을 구현할 수 있는 유일한 방법이다. 메
FundamentalOOP
오브젝트; 객체지향 프로그래밍
이번 장은 이 책을 읽으면서 이해하게 될 다양한 주제들을 얕은 수준으로 가볍게 살펴보는 것 책의 예제 소개를 위한 요구사항 할인 조건 순서 조건 : 상영 순번으로 할인 여부 결정 기간 조건 : 영화 사영시작 시간으로 할인 여부 결정 할인 정책 : 할인 할 요금 결정 금액 할인 정책 : 정액 할인 비율 할인 정책 : 비율 할인 객체지향 패러다임으로 전환은 클래스가 아닌 객체에 초점을 맞출 때에만 얻을 수 있다. 어떤 클래스가 필요한지 고민 하기 전에 어떤 객체들이 필요한지 고민하라 클래스는 공통적인 상태와 행동을 공유하는 객체들을 추