[오브젝트] 21일차. 264-276pg | 의존성, 명시적의존성, new

 

21일차.

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

#요약

**Chapter 08. 의존성 관리하기**
01. 의존성 이해하기
1) 변경과 의존성
2) 의존성 전이
3) 런타임 의존성과 컴파일타임 의존성
4) 컨텍스트 독립성
5) 의존성 해결하기
클래스의 메서드를 호출하는 대부분의 경우에 매번 동일한 객체를 인자로 전달하고 있다면 생성자를 이용하거나 setter 메서드를 이용해 의존성을 지속적으로 유지하는 방식으로 변경하는게 좋다.

02. 유연한 설계
의존성과 결합도의 관계 살펴보기
1) 의존성과 결합도
- 객체의 협력을 위해서는 서로의 존재와 수행 가능한 책임을 알아야 한다. 
- 의존성이 과하면 문제가 된다.

- 바람직한 의존성? 재사용성이 있는 의존성, 컨텍스트에 독립적인 의존성, 느슨한 결합도(loose coupling), 약한 결합도(weak coupling)

 

2) 지식이 결합을 낳는다.

- 결합도의 정도는 한 요소가 자신이 의존하기 있는 다른 요소에 대해 알고 있는 정보의 양으로 결정된다.

- 더 많이 알수록 더 많이 결합되고, 더 많이 알고 있다는 것은 더 적은 컨텍스트에서 재사용 가능하다는 것이다.

- 결합도 느슨하게 하기 -> 협력하는 대상에 대해 필요한 정보 외에는 최대한 감추기-> 추상화

 

3) 추상화에 의존하라

- 추상화 : 어떤 양상, 세부사항, 구조를 좀 더 명확하게 이해하기 위해 특정 절차나 물체를 의도적으로 생략하거나 감춤으로써 복잡도를 극복하는 법

- 의존 대상을 구체 클래스 의존성, 추상 클래스 의존성, 인터페이스 의존성으로 구분하자

- 결합도가 낮은 순서 : 인터페이스 < 추상클래스 < 구체 클래스 의존성

- 인터페이스 의존은 상속계층을 모르더라도 협력이 가능하게 한다 -> 다양한 클래스 상속 계층에 속한 객체들이 동일한 메시지를 수신할 수 있도록 컨텍스트를 확장하는 것을 가능하게 함.

- 의존하는 대상이 더 추상적일수록 결합도는 낮아짐.

 

4) 명시적인 의존성

- 명시적인 의존성(explict dependency) : 의존성은 명시적으로 퍼블릭 인터페이스에 노출된다.

- 숨겨진 의존성(hidden dependency) : 의존성이 퍼블릭 인터페이스에 표현되지 않는다.

- 의존성이 명시적이지 않으면 클래스를 다른 컨텍스트에서 재사용하기 위해 내부 구현을 변경해야 함.

 

5) new는 해롭다.

- new를 잘못사용하면 클래스 사이의 결합도가 극단적으로 높아짐.

- new가 해로운 이유

   a. new를 사용하려면 구체 클래스 이름을 직접 써야 하는데 그러면 new를 사용하는 클라이언트는 추상화가 아닌 추게 클래스에 의존할 수 밖에 없으니 결합도가 높아짐

   b. new는 생성하려는 구체 클래스뿐 아니라 어떤 인자를 이용해 클래스의 생성자를 호출해야 하는지도 알아야 한다. 그래서 new를 쓰면 클라이언트가 알아야 하는 지식의 양이 늘어나니까 결합도가 높아짐

=> 구체 클래스에 직접 의존하면 결합도가 높아짐

- 해결 : 인스턴스를 생성하는 로직과 생성된 인스턴스를 사용하는 로직을 분리

 

6) 가끔은 생성해도 무방하다

- 클래스 안에서 객체의 인스턴스를 직접 생성하는 방식이 유용할 때도 있음.

- 언제냐면, 협력하는 기본 객체를 설정하고 싶은 경우

- 구체 클래스에 의존하게 되더라도 클래스의 사용성이 더 중요하면 결합도를 높이는 방향으로도 코드 작성 가능

 

7) 표준 클래스에 대한 의존은 해롭지 않다.

- 의존성이 왜 불편? 항상 변경에 대한 영향을 암시하니까

- 변경될 확률이 거의 없는 클래스는 의존성이 문제되지 않음.