[오브젝트] 22일차. 277-290pg | 개방-폐쇄 원칙, 추상화

 

22일차.

오브젝트: 코드로 이해하는 객체지향 설계[4주차_목요일]
277-290pg

#요약

**Chapter 08. 의존성 관리하기**
01. 의존성 이해하기
02. 유연한 설계

8) 컨텍스트 확장하기

- 결합도를 낮춤으로써 얻게 되는 컨텍스트의 확장이라는 개념이 유연하고 재사용 가능한 설계를 만든다.

 

9) 조합 가능한 행동

- 어떤 객체와 협력하느냐에 따라 객체의 행동이 달라지는 것은 유연하고 재사용 가능한 설계가 가진 특징

- 유연&재사용 가능한 설계는 객체가 어떻게 하는지를 장황하게 나열하지 않고도 객체들의 조합을 통해 무엇을 하는지를 표현하는 클래스로 구성됨.

- 선언적으로 객체의 행동을 정의할 수 있음

 

---

 

**Chapter 09. 유연한 설계**

- 8장에서 유연하고 재사용가능한 설계를 만드려고 적용할 수 있는 다양한 의존성 관리 기법들을 소개했다면 9장에서는 이 기법들을 원칙이라는 관점에서 정리

 

01. 개방-폐쇄 원칙(Open-Closed Principle, OCP)

- 소프트웨어 개체는 확장에 대해 열려 있어야 하고, 수정에 대해서는 닫혀 있어야 함.

- 확장에 열려 있다 : 애플리케이션의 요구사항이 변경될 때 이 변경에 맞게 새 '동작'을 추가해서 애플리케이션의 기능을 확장할 수 있음

- 수정에 대해 닫혀있다 : 기존의 '코드'를 수정하지 않고도 애플리케이션의 동작을 추가하거나 변경할 수 있음

 

1) 컴파일타임 의존성을 고정시키고 런타임 의존성을 변경하라

- 런타임 의존성 : 실행할 때 협력에 참여하는 객체들 사이의 관계

- 컴파일타임 의존성 : 코드에서 드러나는 클래스들 사이의 관계

- 개방폐쇄 원칙을 수용하는 코드는 컴파일타임 의존성을 수정하지 않고도 런타임 의존성을 쉽게 변경할 수 있다.

 

2) 추상화가 핵심이다.

- 개방폐쇄 원칙의 핵심은 추상화에 의존하는 것.

- 추상화 부분은 수정에 대해 닫혀있다. 추상화를 통해 생략된 부분은 확장의 여지를 남긴다 -> 이게 추상화가 개방폐쇄 원칙을 가능하게 하는 이유

- 추상화를 했다고 해서 모든 수정에 대해 설계가 폐쇄되는 것은 아니다.

 

02. 생성 사용 분리

- 결합도가 높을수록 개방폐쇄 원칙을 따르는 구조를 설계하기 어려워진다.

- 동일 클래스에서 객체 생성과 사용의 두 가지 이질적 목적을 가진 코드가 공존하는 것이 문제 -> 객체와 관련된 두 책임을 서로 다른 객체로 분리해야 함.

- 객체에 대한 생성과 사용을 분리.

- 사용으로부터 생성을 분리하는 방법은 객체를 생성할 책임을 클라이언트로 옮기는 것.

 

1) FACTORY 추가하기

- 생성과 사용을 분리하기 위해 객체 생성에 특화된 객체를 factory라고 한다.