[오브젝트] 23일차. 291-304pg | 의존성 주입, 의존성 역전

 

 

23일차.

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

 

 

#요약

 

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

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

 

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

02. 생성 사용 분리

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

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

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

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

 

1) FACTORY 추가하기

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

 

2) 순수한 가공물에게 책임 할당하기

- 책임할당의 기본 원칙은 책임 수행에 필요한 정보를 가장 많이 알고있는 Information expert에게 책임을 할당하는 것.

- 시스템을 객체로 분해하는 방식 : 표현적 분해, 행위적 분해

- 표현적 분해 : 도메인에 존재하는 사물 또는 개념을 표현하는 객체들을 이용해 시스템을 분해하는 것. 객체지향 설계를 위한 가장 기본적인 접근법

- 순수한 가공물 : 책임을 할당하기 위해 창조되는 도메인과 무관한 인공적인 객체

- 어떤 행동을 추가하려고 했는데 책임질 마땅한 도메임이 없으면 순수한 가공물을 추가하고 이 객체에 책임을 할당하ㄴ다.

- 따라서 순수한 가공물은 표현적 분해보다 행위적 분해에 의해 생성된다.

- 순수한 가공물( pure fabrication 패턴) : information expert 패턴에 따라 책임을 할당한 결과가 별로일 경우 대안으로 사용됨. 적절한 대안이 없을 때 사람들이 창조적인 무언가를 만들어낸다는 의미.

- factory는 객체의 생성 책임을 할당할만한 도메인 객체가 존재하지 않을 때선택할 수 있는 순수한 가공물임.

 

03. 의존성 주입

- 의존성 주입 : 사용하는 객체가 아닌 외부 독립적 객체가 인스턴스를 만든 후에 이를 전달해서 의존성을 해결하는 방법

근데 왜 주입이냐? 외부에서 의존성의 대상을 해결한 후 이를 사용하는 객체 쪽으로 주입하기 떄문.
- 의존성 주입에서 의존성을 해결하는 3가지 방법

   a. 생성자 주입 : 객체를 생성하는 시점에 생성자를 통한 의존성 해결

   b. setter 주입 : 객체 생성 후 setter 메서드를 통한 의존성 해결

   c. 메서드 주입 : 메서드 실행시 인자를 이용한 의존성 해결

'

- setter 주입 단점 : 객체가 생성되기 위해 어떤 의존성이 필수적인지를 명시적으로 표현 못함.

- 메서드 주입은 메서드 호출 주입이라고도 한다. 메소드가 의존성을 필요로 하는 유일한 경우에만 사용 가능

- 생성자 주입을 통해 의존성을 전달받으면 객체가 올바른 상태로 생성되는 데 필요한 의존성을 명확하게 표현할 수 있지만 주입된 의존성이 한 두 개의 메서드에서만 사용된 각 메서드 인자로 전달하는게 더 낫다.

 

1) 숨겨진 의존성은 나쁘다.

- 의존성 주입 외에 의존성을 해결하는 다양한 방법들.

- Service location 패턴 : 의존성을 해결할 객체들을 보관하는 일종의 저장소. 하지만 선호하지 않음. 그 이유는 얘는 의존성을 감춤.

- 숨겨진 의존성이 어려운 이유 : 디버깅 어렵고 문제점을 발견할 수 있는 시점이 코드작성 시점이 아니라 실행시점임.

- 숨겨진 의존성은 의존성을 이해하기 위해서 코드 내부 구현을 이해해야만 한다. 그래서 숨겨진의존성은 캡슐화를 위반함.

- 가능하면 의존성을 명시적으로 표현하기

 

 

04. 의존성 역전 원칙

1) 추상화와 의존성 역전

- 대부분 우리가 재사용하려는 대상읜 상위 수준의 클래스인데, 상위 수준 클래스가 하위 수준 클래스에 의존하면 상위 수준 클래스를 재사용할 떄 하위 수준 클래스도 필요하기 때문에 재사용하기 어려워진다.

- 하위수준의 이슈로 상위수준의 클래스들을 재사용하는 게 어렵다면 해결사는 추상화.

- 1. 상위 수준 모듈은 하위 수준 모듈에 의존하지 말고 모두 추상화에 의존할 것.

- 2. 추상화는 구체적인 사항에 의존하면 안되고 구체적인 사항이 추상화에 의존해야 한다.

=> 이것이 의존성 역전 원칙

 

2) 의존성 역전 원칙과 패키지

- 역전은 의존성의 방향 말고도 인터페이스의 소유권에도 적용된다.

- 의존성 역전 원칙에 따라 상위 수준의 협력 흐름을 재사용ㅇ하려면 추상화가 제공하는 인터페이스의 소유권도 역전시켜야 함.

- 유연하고 재사용 가능하며 컨텍스트에 독립적인 설계는 전통적인 패러다임이 고수하는의존성의 방향을 역전시킨다.