[오브젝트] 22일차

da__ell·2023년 8월 27일
0

독서 - 오브젝트

목록 보기
22/25
post-thumbnail

p. 277 ~ p. 290

컨텍스트 확장하기

조합 가능한 행동

다양한 종류의 정책이 필요한 컨텍스트에서 정책들을 재사용할 수 있는 이유는 코드를 직접 수정하지 않고 협력 대상 인스턴스를 교체할 수 있기 때문이다.

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

9. 유연한 설계

9-1. 개방 - 폐쇄 원칙

확장 가능하고 변화에 유연하게 대응할 수 있는 설계를 만드는 원칙 중 하나로 개방-폐쇄 원칙을 고안했다. 여기서 중요한 키워드는 확장과 수정이다.

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

개방-폐쇄 원칙을 수용하는 코드는 컴파일타임 의존성을 수정하지 않고도 런타임 의존성을 쉽게 변경할수 있다. 의존성의 관점에서 개방-폐쇄 원칙을 따르는 설게란 컴파일타임 의존성은 유지하면서 런타임 의존성의 가능성을 확장하고 수정할 수 있는 구조라고 할 수 있다.

추상화가 핵심이다.

개방-폐쇄 원칙의 핵심은 추상화에 의존하는 것이다. 추상화는 핵심적인 부분만 남기고 불필요햔 부분은 생략하여 복잡성을 극복하는 기법이다. 개방-폐쇄 원칙의 관점에서 생략되지 않고 남겨지는 부분은 다양한 상황에서의 공통점을 반영한 추상화의 결과물이다. 공통적인 부분은 문맥이 바뀌더라도 변하지 않아야 한다 → 수정할 필요가 없어야 한다.

어떤 개념을 추상화했다고 해서 수정에 대해 닫혀 있는 설계를 만들 수 있는 것은 아니다 폐쇄를 가능하게 하는 것은 의존성의 방향이다.

명시적 의존성과 의존성 해결방법을 통해 컴파일타임 의존성을 런타임 의존성을 대체함으로써 실행 시에 객채의 행동을 확장할 수 있다. 변경에 의한 파급효과를 최대한 피하기 위해서는 변하는 것과 변하지 않는 것을 이해하고 이를 추상화의 목적으로 삼아야 한다.

9-2. 생성 사용 분리

결합도가 높아질수록 개방-폐쇄 원칙을 따를 구조를 설계하기가 어려워진다. 객체 생성에 대한 지식은 과도한 결합도를 초래하는 경향이 있다. 문제는 부적절한 곳에서 객체를 생성한다는 것이다. 동일한 클래스 안에서 객체 생성과 사용이라는 두 가지 이질적인 목적을 가진 코드가 공존하는 것이 문제이다.

유연하기 재사용 가능한 설계는 객체와 관련된 여러 책임들을 서로 다른 객체로 분리해야 한다. 객체에 대한 생성과 사용을 분리해야 한다.

사용으로부터 생성을 분리하는 데 사용되는 가장 보편적인 방법은 객체를 생성할 책임을 클라이언트로 옮기는 것이다.

Factory 추가하기

객체 생성과 관련된 지식이 협력하는 클라이언트에까지 새어나가기 원하지 않는다고 가정하자. 객체 생성과 관련된 책임만 전담하는 별도의 객체를 추가하고 다른 클래스가 객체를 사용하도록 만들 수 있다. 생성과 사용을 분리하기 위해 객체 생성에 특화된 객체를 FACTORY라고 부른다.

profile
daelkdev@gmail.com

0개의 댓글