p. 264 ~ p. 276
8-2. 유연한 설계
의존성과 결합도
의존성을 통해 객채의 협력이 가능하지만 과하면 문제가 될 수 있다. 다양한 환경에서 클래스를 재사용할 수 없도록 제한한다면 바람직 못한 의존성이다. 다양한 환경에서 재사용 가능한 것이 바람직한 의존성이다.
두 요소 사이에 존재하는 의존성이 바람직 할때 느슨한 결합도, 약한 결합도를 가지는것
지식이 결합을 낳는다
결합도의 정도는 한 요소가 자신의 의존하고 있는 정보의 양으로 결정된다.
더 많이 알수록 더 많이 결합된다. 결합도를 느슨하기 유지하기 위해 협력하는 대상에 대해 필요 정보 외에는 최대한 감추는 것이 중요하다.
추상화에 의존하라
추상화를 통해 불필요한 정보를 감춤으로써 대상에 대한 지식을 줄이고 결합도를 느슨하게 유지할 수 있다.
인터페이스에 의존하면 상속 계층을 모르더라도 협력이 가능해진다.
중요한 것은 실행 컨텍스트에 대해 알아야 하는 정보를 줄일 수록 결합도가 낮아진다는 것이다.
→ 구체적인 클래스보다 추상 클래스에 추상 클래스보다 인터페이스에 의존하도록 만드는 것이 효과적
명시적인 의존성
결합도를 느슨하게 만들기 위해서는 인스턴스 변수의 타입을 추상 클래스나 인터페이스로 선언하는 것 만으로는 부족하다.
의존성의 대상을 생성자의 인자로 선언하는 방법은 퍼블릭 인터페이스에 드러내는 것은 setter 메서드를 사용하는 방식은 의존성이 명시적으로 노출되어 명시적인 의존성이라고도 부른다.
의존성이 표현되지 않는 것은 숨겨진 의존성이다.
의존성은 명시적으로 표현되어야 한다. 퍼블릭 인터페이스를 통해 명시적으로 드러내야한다.
new는 해롭다.
new를 잘못 사용하면 추상화가 아닌 구체 클래스에 의존할 수밖에 없기 때문에 결합도가 높아진다.
new 연산자는 어던 인자를 통해 클래스의 생성자를 호출하는 지도 알아야 한다 → 클라이언트가 알아야 하는 지식의 양이 늘어나기 때문에 결합도가 높아진다.
이를 해결하기 위해 생성자의 인자로 전달하거나, setter 메서드를 사용하거나, 실행 시에 메서드의 인자로 전달하면 된다.
사용과 생성의 책임을 분리해서 결합도를 낮추면 설계를 유연하게 만들 수 있다.
가끔은 생성해도 무방하다
모든 경우에 인스턴스를 생성하는 책임을 클라이언트로 옮긴다면 클라이언트들 사이에 중복 코드가 늘어나고 사용성도 나빠질 것이다.
이를 해결하기 위해 기본 객체를 생성하는 생성자를 추가하고 생성자에서 인스턴스를 인자로 받는 생성자를 체이닝하는 것이다.
설계는 트레이드 오프이다.
표준 클래스에 대한 의존은 해롭지 않다
의존성이 불편한 이유는 그것이 항상 변경에 대한 영향을 암시하기 때문이다.
클래스를 직접 생성하더라도 가능한 한 추상적인 타입을 사용하는 것이 확장성 측면에서 유리하다.
