본문으로 건너뛰기

#조영호

14
FundamentalOOP

오브젝트; 변경과 유연성과 리팩토링

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

오브젝트; GRASP와 책임 할당하기

데이터를 먼저 결정하고 고립된 객체의 상태에 초점을 맞추면 캡슐화를 위반하기 쉽고, 요소들 사이의 결합도가 높아지며, 코드를 변경하기 어려워진다. 책임에 초점을 맞춰서 설계할 때 어떤 객체에게 어떤 책임을 할당할지를 결정 하는 것이 어렵다. 책임 할당 과정은 트레이드오프 활동이다. 데이터 중심의 설계에서 책임 중심의 설계로 전환하는 방법 클라이언트 관점에서 객체가 수행하는 행동이란 곧 객체의 책임을 의미한다. 객체는 협력에 참여하기 위해 존재하며 협렵 안에서 수행하는 책임이 객체의 존재가치를 증명한다. 너무 이른시기에 데이터에 초점
FundamentalOOP

오브젝트; 데이터 중심 설계의 문제

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

오브젝트; 역할, 책임, 협력

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

오브젝트; 객체지향 프로그래밍

이번 장은 이 책을 읽으면서 이해하게 될 다양한 주제들을 얕은 수준으로 가볍게 살펴보는 것 책의 예제 소개를 위한 요구사항 할인 조건 순서 조건 : 상영 순번으로 할인 여부 결정 기간 조건 : 영화 사영시작 시간으로 할인 여부 결정 할인 정책 : 할인 할 요금 결정 금액 할인 정책 : 정액 할인 비율 할인 정책 : 비율 할인 객체지향 패러다임으로 전환은 클래스가 아닌 객체에 초점을 맞출 때에만 얻을 수 있다. 어떤 클래스가 필요한지 고민 하기 전에 어떤 객체들이 필요한지 고민하라 클래스는 공통적인 상태와 행동을 공유하는 객체들을 추
FundamentalOOP

오브젝트; 객체, 설계

이론보다 실무가 먼저다. 설계에 관한 이론은 1970년이 되서야 등장했다. 설계에 대한 이론은 있으나 유지보수에 대한 이론은 없다. 객체지향 프로그램을 설계하고 유지보수하는 데 필요하는 원칙과 기법을 설명하는것이 목적이다. 코드 보기 소프트웨어 모듈의 목적 실행 중에 제대로 동작하는 것이다. 변경을 위해 존재한다. 대부분의 모듈은 생명주기 동안 변경되기 때문에 간단한 작업 만으로도 변경이 가능해야 한다. 코드를 읽는 사람과 의사소통 하는것. 현실의 프로세스와 벗어난 비즈니스 로직은 코드를 읽는 사람과 제대로된 소통이 되지 않는다.