8장 의존성 관리하기

8장 읽고 이야기 나눈 내용

• new는 해롭다. 그럼 어디에 둬야해? 생성자로 넘겨도 new는 써야하는 것 아닌가? → 팩토리 메소드처럼 의도적으로 높은 결합도를 갖는 대신 명시적인 의존성을 가진 클래스를 두는 방법도 있다.
• 그냥 읽을 때는 왜 이렇게 하는지 이해하지 못했는데, 나중에 컨텍스트를 확장해서 다른 요구사항을 추가하더라도 클래스만 추가해서 기능을 바꾸는 것이 인상적이었다.
• 하지만 이러한 설계가 꼭 필요한가 싶기도 하다. 유연함이 필요하지 않다면 클래스가 너무 많아지고 흐름 파악이 어려워보인다.
• 그 말을 들으니 기술 커뮤니티에서 들어본 기술부채라는 용어가 떠오른다. 우선 기한 안에 필요한 요구사항을 모두 구현하고, 따로 시간을 들여 더러운 코드를 정리하거나 유연함이 필요한 부분의 설계를 개선한다고 들었다. 코드 퀄리티에 신경을 많이 쓰는 회사는 기술부채를 상환하는 시간을 따로 주기도 한다고. 저도 그런 회사 가고싶네요.
• 디자인 패턴에 여기서 소개된 객체지향적 접근이 많이 적용된 것 같아서 다음엔 디자인 패턴을 공부해보고 싶다. 좋은 생각이에요.

 

의존성과 의존성 전이

• 과한 의존성은 강한 결합도를 유발하므로 잘 제어해야함
• 의존성은 함께 변경될 수 있는 가능성
• 코드로 직접 참조하지 않더라도, 간접적으로도 의존성이 전이될 수 있음
• 의존성이 전이되더라도 캡슐화를 잘 했다면 변경이 전파되지 않음

 

런타임 의존성과 컴파일타임 의존성

• 런타임 의존성 : 실행되는 시점의 객체 의존성
• 컴파일타임 의존성 : 코드를 작성하는 시점의 클래스 의존성
• 코드 작성 시점에는 ‘어떻게’를 모르게 하고, 이를 런타임에 결정하게 만든다 → 의존성 해결
• 컴파일 타임의 구조와 런타임 구조가 멀수록 설계가 유연하고 재사용 가능함

 

의존성 해결

• 생성자 : 추상 타입에 실제 인스턴스 전달
• 세터 : 실행 중에 의존 대상 변경 가능. 다만 설정이 안된 경우 객체 상태가 불완전함
• 생성자로 완전한 상태의 객체를 생성하고, 필요에 따라 의존 대상 변경
• 인자 : 일시적으로 의존관계가 존재하거나, 메소드를 실행할 때마다 의존 대상이 매번 달라짐

 

바람직한 의존성

• 바람직한 의존성은 협력을 위해 꼭 필요한 것
• 다른 환경에서 재사용하기 위해 내부 구현을 변경하게 만드는 의존성은 재사용의 관점에서 바람직하지 않다. 예를 들어 생성자 내부에서 구체적인 클래스를 결정하는 의존성
• 필요한 의존성은 명시적으로 드러내야한다.

 

의존성 관리 팁

• 클라이언트가 알고있는 지식이 적을수록 결합도가 느슨해짐 (구체 > 추상 > 인터페이스)
• 생성에 사용할 구체적인 내용을 클라이언트가 결정하도록 미루기. 클래스의 생성자에는 추상 타입만 남는다.
• 표준 클래스는 변경할 이유가 적으므로 의존해도 됨