Book/오브젝트

13. 코드로 이해하는 합성(2/2) | 오브젝트 11장

3. 합성 관계로 변경하기 상속 관계는 컴파일타임에 결정되고 고정되기 때문에 코드를 실행하는 도중에는 변경할 수 없다. 따라서 여러 기능을 조합해야 하는 설계의 경우 클래스 폭발 문제가 발생하게 된다. 합성은 컴파일타임 관계를 런타임 관계로 변경함으로써 이 문제를 해결한다. 컴파일타임 의존성과 런타임 의존성의 거리가 멀수록 설계가 유연하다. 상속은 컴파일타임 의존성과 런타임 의존성을 동일하게 만든다. 합성은 퍼블릭 인터페이스를 사용하여 두 의존성을 다르게 만들 수 있다. 두 의존성의 거리가 멀수록 설계의 복잡도는 상승하지만, 변경에 따르는 고통이 커지고 있다면 유연성을 택하는 것이 좋다. 합성을 사용하면 구현 시점에 정책들의 관계를 고정시킬 필요가 없으며 실행 시점에 유연하게 변경할 수 있다. 상속: 조..

12. 코드로 이해하는 합성(1/2) | 오브젝트 11장

코드 재사용 기법 상속: 부모 클래스와 자식 클래스를 연결해서 부모 클래스의 코드를 재사용 두 객체 사이의 의존성은 컴파일타임에 해결된다. is-a 관계 합성: 전체를 표현하는 객체가 부분을 표현하는 객체를 포함해서 부분 객체의 코드를 재사용 두 객체 사이의 의존성은 런타임에 해결된다. has-a 관계 합성은 상속과 달리 구현에 의존하지 않는다. 합성은 구현이 아닌 퍼블릭 인터페이스에 의존한다. 상속 관계는 코드 작성 시점에 결정한 후 변경이 불가능한 정적인 관계이지만, 합성 관계는 실행 시점에 동적으로 변경할 수 있는 동적인 관계다. 상속은 부모 클래스 안에 구현된 코드 자체를 재사용하지만, 합성은 포함되는 객체의 퍼블릭 인터페이스를 재사용한다. 1. 상속을 합성으로 변경하기 상속을 남용했을 때의 문제..

11. 코드로 이해하는 상속과 코드 재사용 | 오브젝트 10장

코드를 재사용하는 방법 전통적인 패러다임: 코드를 복사한 후 수정 객체지향 패러다임: 새로운 클래스 추가 상속: 클래스를 재사용하기 위해 새로운 클래스를 추가하는 가장 대표적인 방법 합성: 새로운 클래스의 인스턴스 안에 기존 클래스의 인스턴스를 포함시키는 방법 1. 상속과 중복 코드 DRY (반복하지 마라) 원칙 Once and Only Once 원칙 또는 Single-Point Control 원칙이라고도 부른다. 코드 안에 중복이 있어서는 안 된다는 것이다. 한 달에 한 번씩 가입자별로 전화 요금을 계산하는 코드를 예시로 보자. class Call { private from: number; private to: number; constructor(from: number, to: number) { thi..

10. 코드로 이해하는 유연한 설계 | 오브젝트 9장

8장에서 살펴본 의존성 관리 기법들을 원칙이라는 관점에서 정리해보자. 1. 개방-폐쇄 원칙 소프트웨어 개체(클래스, 모듈, 함수 등)는 확장에 대해 열려 있어야 하고, 수정에 대해서는 닫혀 있어야 한다. 확장에 대해 열려 있다 애플리케이션의 요구사항이 변경될 때 새로운 '동작'을 추가해서 기능을 확장할 수 있다. 수정에 대해 닫혀 있다 기존 '코드'를 수정하지 않고도 동작을 추가하거나 변경할 수 있다. 컴파일타임 의존성을 고정시키고 런타임 의존성을 변경하라 컴파일타임 의존성: 코드에서 드러나는 클래스들 사이의 관계 런타임 의존성: 실행 시에 협력에 참여하는 객체들 사이의 관계 할인 정책 설계의 경우, 확장에 대해 열려 있다 새로운 할인 정책을 추가해서 기능을 확장할 수 있도록 허용한다. 수정에 대해 닫혀..

9. 코드로 이해하는 의존성 관리 | 오브젝트 8장

협력은 필수적이지만 과도한 협력은 과도한 의존성을 낳아 애플리케이션을 수정하기 어렵게 만든다. 1. 의존성 이해하기 변경과 의존성 의존성은 실행 시점과 구현 시점에 서로 다른 의미를 가진다. 실행 시점: 의존하는 객체가 정상적으로 동작하기 위해서는 실행 시에 의존 대상 객체가 반드시 존재해야 함 구현 시점: 의존 대상 객체가 변경될 경우 의존하는 객체도 함께 변경됨 class PeriodCondition implements DiscountCondition { private dayOfWeek: DayOfWeek; private startTime: LocalTime; private endTime: LocalTime; public isSatisfiedBy(screening: Screening): boolean..

8. 객체에게 로직을 분배하는 방법, 객체 분해 | 오브젝트 7장

실제로 문제를 해결하기 위해 사용하는 저장소는 장기 기억이 아닌 단기 기억이다. 문제 해결에 필요한 요소의 수가 단기 기억의 용량을 초과하는 순간 인지 과부하가 발생한다. 인지 과부화를 방지하기 위해 불필요한 정보를 제거하고 현재의 문제 해결에 필요한 핵심만 남기는 작업이 추상화다. 가장 일반적인 추상화 방법은 한 번에 다뤄야 하는 문제의 크기를 줄이는 것이다. 큰 문제를 해결 가능한 작은 문제로 나누는 작업이 분해다. 추상화를 더 큰 규모의 추상화로 압축시킴으로써 단기 기억의 한계를 초월할 수 있다. 1. 프로시저 추상화와 데이터 추상화 프로그래밍 패러다임은 다음 두 가지로 결정된다. 프로그래밍을 구성하기 위해 사용하는 추상화의 종류 이 추상화를 이용해 소프트웨어를 분해하는 방법 모든 프로그래밍 패러다..

7. 코드로 이해하는 메시지와 인터페이스 | 오브젝트 6장

훌륭한 객체지향을 위해서는 클래스가 아닌 객체를 지향해야 한다. 협력 안에서 객체가 수행하는 책임에 추점을 맞춰야 한다. 책임은 객체가 수신할 수 있는 메시지의 기반이 된다. 객체지향 애플리케이션의 가장 중요한 재료는 객체들이 주고받는 메시지다. 매시지들이 객체의 퍼블리 인터페이스를 구성한다. 1. 협력과 메시지 클라이언트-서버 모델 클라이언트: 메시지를 전송하는 객체 Screening은 '가격을 계산하라' 메시지를 전송함으로써 도움 요청 Movie는 '할인 요금을 계산하라' 메시지를 전송함으로써 도움 요청 서버: 메시질르 수신하는 객체 Movie는 가격을 계산하는 서비스를 제공함으로써 메시지에 응답 DiscountPolicy는 할인 요금을 계산하는 서비스를 제공함으로써 메시지에 응답 협력: 클라이언트가..

6. 코드로 이해하는 객체의 책임 할당, GRASP 패턴 | 오브젝트 5장

어떤 객체에게 어떤 책임을 할당할지를 결정하는 것은 쉽지 않다. 책임 할당 과정은 일종의 트레이드오프이며, 올바른 책임을 할당하기 위해서는 다양한 관점에서 설계를 평가할 수 있어야 한다. 이번에 살펴볼 GRASP 패턴은 책임 할당의 어려움을 해결해준다. 1. 책임 주도 설계를 향해 데이터보다 행동을 먼저 결정하라 데이터는 책임을 수행하는 데 필요한 재료를 제공할 뿐이다. 객체의 데이터에서 행동으로 무게 중심을 옮겨야 한다. 데이터 중심 설계 이 객체가 포함해야 하는 데이터가 무엇인가 => 데이터를 처리하는 데 필요한 오퍼레이션은 무엇인가 책임 중심 설계 이 객체가 수행해야 하는 책임은 무엇인가 => 이 책임을 수행하는 데 필요한 데이터는 무엇인가 협력이라는 문맥 안해서 책임을 결정하라 책임의 품질은 협력..