본문 바로가기

IT Book Summary/Object: 객체지향설계

 (16)
Chapter 10 상속과 코드 재사용 클래스를 재사용하기 위해 새로운 클래스를 추가하는 가장 대표적인 방법 - 상속 새로운 클래스의 인스턴스 안에 기존 클래스의 인스턴스를 포함시키는 방법 - 합성 01 상속과 중복 코드 DRY원칙(Don't Repeat Yourself) 요구사항이 변경됐을때 두 코드를 함께 수정해야 한다면 이 코드는 중복이다. 수정과 테스트에 드는 비용을 증가시킬뿐 코드가 변경에 반응하는 방식이 중요하다. 중복과 변경 중복코드 살펴보기 ex) 한달에 한번씩 가입자별 전화 요금을 계산하는 애플리케이션 개별 통화기간을 저장하는 Call 클라스 Call은 통화 시작 시간(from)과 통화 종료 시간(to)을 인스턴스 변수로 포함 Call 의 목록을 관리할 정보 전문가 Phone 단위요금을 저장하는 amount 단위시간을 저장하는..
Chapter 09 유연한 설계 설계원칙을 통해 의존성 관리 기법을 정리해보자. 01 개방-폐쇄 원칙(Open-Closed Principle, OCP) - 소프트웨어 개체(클래스, 모듈, 함수 등등)는 확장에 대해 열려있어야 하고, 수정에 대해 닫혀있어야한다 확장에 대해 열려있다 : 애플리케이션의 요구사항이 변경될 때 이 변경에 맞게 새로운 '동작'을 추가해서 기능을 확장할 수 있다 수정에 대해 닫혀있다 : 기존의 '코드'를 수정하지 않고도 애플리케이션의 동작을 추가하거나 변경할 수 있다. 컴파일타임 의존성을 고정시키고 런타임 의존성을 변경하라 런타임 의존성 - 실행시에 협력에 참여하는 객체들 사이의 관계 컴파일타임 의존성 - 코드에서 드러나는 클래스들 사이의 관계 [Movie] -> [DiscountPolicy] | | [Percen..
Chapter 08 의존성 관리하기 협력은 객체가 다른 객체에 대해 알것을 강요함. - 협력할 객체가 존재한다는 사실 - 객체가 수신할 수 있는 메세지에 대한 사실 -> 이런 지식이 객체 사이의 의존성을 낳음. 객체 지향 설계의 핵심 - 협력을 위해 필요한 의존성은 유지, 변경을 방해하는 의존성은 제거 유연한 객체를 만들기 위해 의존성을 관리하는 방법? 01 의존성 이해하기 변경과 의존성 의존성은 실행 시점과 구현 시점에 다른의미를 가짐 실행시점 : 의존하는 객체가 정상적으로 동작하기 위해서는 실행 시에 의존 대상객체가 반드시 존재해야 함. 구현시점 : 의존 대상 객체가 변경될 경우 의존하는 객체도 함께 변경됨. ex) 영화예매 시스템의 PeriodCondition 클래스의 의존성 개념 public class PeriodCondition ..
Chapter 07 객체분해 단기 기억과 장기기억 문제해결에 필요한 요소의 수가 단기 기억의 용량을 초과하는 순간 문제 해결 능력이 급격히 떨어지는것 인지 과부하(cognitive overload) 발생 -> 단기기억안에 보관할 정보의 양을 조절하기위해 불필요한 정보를 제거, 현재 문제 해결에 필요한 핵심 정보만 남기는 작업(추상화) 큰 문제를 한번에 해결 가능한 작은 단위로 나누는 작업 분해(decomposition) 추상화를 더 큰 규모의 추상화로 압축시킴으로써 단기 기억의 한계를 초월할 수 있음. 복잡성의 문제를 추상화와 분해로 해결 01 프로시저 추상화와 데이터 추상화 어셈블리어 - 기계어에 인간이 이해할 수 있는 상징을 부여하려는 노력의 결과 고수준 언어 - 인간의 눈높이에 맞게 의미 있는 추상화를 시도한 결과 프로그래밍을..
Chapter 06 메시지와 인터페이스 객체지향 프로그래밍의 흔한 오해 - 어플리케이션이 클래스 집합으로 구성된다는 것. 클래스라는 구현도구에 집착하면 경직되고 유연하지 못한 설계에 이를 확률이 높아짐. 클래스가 아니라 객체를 지향해야한다. 애플리케이션은 클래스로 구성되지만 메시지를 통해 정의된다. 객체가 수신하는 메시지들이 객체의 퍼블릭 인터페이스를 구성한다. 이번장의 주제는 유연하고 재사용 가능한 퍼블릭 인터페이스를 만드는 원칙과 기법이다. - 구현과 부수효과는 캡슐화 하고 높은 응집도와 낮은 결합도를 가진 인터페이스를 만들 수 있는 지침을 제공하는 원칙들 01. 협력과 메시지 클라이언트-서버 모델 (전통적인 메타포) ( 클라이언트 ) 객체는 메시지로 요청 -> 수신한 ( 서버 ) 객체는 요청을 처리한 후 응답 단방향 상호작용 ex) 무비..
Chapter 05 책임 할당하기 책임 할당 과정은 일종의 트레이드 오프 활동 다양한 책임 할당 방법이 존재 GRASP 패턴 - 다양한 기준에 따라 책임을 할당하고 결과를 트레이드 오프 하는 기준 01 책임 주도 설계를 향해 데이터보다 행동을 먼저 결정하라 객체의 행동 -> 데이터 수행해야할 책임은 무엇인가? -> 이 책임을 수행하는데 필요한 데이터는 무엇인가? 협력이라는 문맥 안에서 책임을 결정하라 객체에 할당된 책임의 품질은 협력에 적합한 정도로 결정. 객체가 참여하는 협력에 적합하다면 좋은 책임이다. 메시지가 객체를 선택하게 하자. 클래스 기반 설계에서 메시지 기반 설계로의 자리바꿈은 우리가 해오던 설계 활동의 전환점이다. "메시지를 전송해야 하는데 누구에게 전송해야 하지?" 라고 질문하는 것. 객체를 가지고 있기 때문에 메시지를 ..
Chapter 04 설계 품질과 트레이드 오프 객체지향 설계 -> 올바른 객체에게 올바른 책임을 할당. 낮은 결합도와 높은 응집도를 가진 구조를 창조 두가지 관점 - 설계의 핵심은 책임. 책임을 할당하는 작업이 응집도와 결합도 같은 설계품질과 연관. 훌륭한 설계란? 합리적인 비용 안에서 쉽게 변경할 수 있는 설계 객체의 상태가 아니라 행동, 책임에 초점. 이번장에서는 책임이 아닌 상태를 표현하는 데이터 중심 설계를 보고 차이점을 살펴보자. 01. 데이터 중심의 영화예매 시스템 객체의 상태 == 객체가 저장해야하는 데이터의 집합 두가지 방법 객체 분할 데이터(상태) 중심 책임 중심 자신이 가지는 데이터를 조작하는데 필요한 오퍼레이션을 정의 다른객체가 요청할 수 있는 오퍼레이션을 위해 상태를 보관 객체의 상태에 초점 객체의 행동에 초점 독립된 데이터 덩..
Chapter03 역할, 책임, 협력 객체지향 패러다임의 관점에서 핵심 -> 역할(role), 책임(responsibility), 협력(collaboration) 본질은 협력하는 객체들의 공동체를 창조하는 것. 협력을 구성하기 위해 적절한 객체를 찾고 적절한 책임을 할당하라. 이와같은 것을 고민하지 않고 구현에 먼저 초점을 맞추게 된다면 변경하기 어렵고 유연하지 못한 코드가 된다. 01. 협력 영화 예매 시스템을 돌아보자 -. 영화 예매라는 기능을 위해 협력하는 객체들의 상호작용함 객체들은 요청의 흐름을 따라 자신에게 분배된 로직을 실행하면서 전체기능을 완성. 메세지를 주고받으며 상호작용하는 것을 협력 객체가 협력에 참여하기 위해 수행하는 로직을 책임 객체들이 협력안에 수행하는 책임들이 모여 구성하는것 객체가 수행하는 역할 로직을 수행하며 ..

티스토리툴바