[오브젝트] 9장 '유연한 설계'

9장에서는 이전에 설명한 의존성을 관리하는 방법을 정의된 설계 원칙에 근거해 다시 설명한다. 

 

저번주에 디자인 패턴에서 팩토리 메소드를 공부할 때  이해가 잘 안 됐었는데, 

이번 오브젝트 9장을 읽으면서 왜 생성하는 부분을 분리하는 클래스를 만들어야 하는지에 대한 이유를 알게 되었다. 

이것도 역시 객체지향적인 설계, 즉 결합도를 낮추고 재사용성을 높이기 위해서인데 의존성 변경의 영향을 최소화 하기위해 추상화에만 의존하게 만들려면 객체가 구체 클래스의 인스턴스를 생성하면 안 된다. 그래서 도메인 개념에 할당돼 있던 객체 생성 책임을 도메인 개념과 아무 상관이 없는 가공의 객체, factory로 옮긴 것이다. 

 

 

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

- 확장에는 열려있고, 수정에는 닫혀 있어야 한다.

-> 컴파일 타임 의존성은 유지하면서 런타임 의존성은 확장/수정 가능

-> 이렇게 하려면 모든 요소가 추상화에 의존해야 함.

 

객체의 생성과 사용을 분리하는 방법 (separating use from creation)?

- 객체 생성은 클라이언트에서 해야함

- 또는 객체 생성과 관련된 책임만 전담하는 별도의 객체 추가

-> 이런 객체를 Factory라고 부름

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

(pure fabrication은 책임을 할당하기 위해 창조되는 도메인과 무관한 인공적인 객체를 의미한다)

 

의존성 주입이란 (Dependency Injection)?

사용하는 객체가 아닌 외부의 독립적인 객체가 인스턴스를 생성한 후 이를 전달해서 의존성을 해결하는 방법(p.293)

의존성 주입은 의존성을 해결(컴파일 타임 의존성과 런타임 의존성의 차이점 해소) 하기 위해 의존성을 객체의 퍼블릭 인터페이스에 명시적으로 드러내서 외부에서 필요한 런타임 의존성을 전달할 수 있도록 만드는 방법.

 

1. 생성자 주입(constructor injection)

2. setter 주입(setter injection)

3. 메서드 주입(method injection)

 

이 부분도 스프링을 공부하면서 정말... 들을 때마다 생소했던 용어인데, 왜 의존성 주입이라고 불리냐면 외부에서 의존성의 대상을 해결한 후 이를 사용하는 객체에 주입하기 때문이다. 예를 들어, 내가 핸드폰을 사용하는 것을 나는 핸드폰에 의존한다고 할 수 있는데 이때 내가 핸드폰을 사용하기 위해서 생성도 하고 사용도 하는 것이 아니라 누군가, 아마도 팩토리가 핸드폰을 생성해서 나에게 주는 것으로 이해했다.  

 

// TODO

의존성 주입 다시 읽어보기

 

의존성 역전 원칙이란 (Dependency Inversion Principle, DIP)?

1. 상위 수준의 모듈은 하위 수준의 모듈에 의존해서는 안 된다. 둘 모두 추상화에 의존해야 한다.
2. 추상화는 구체적인 사항에 의존해서는 안된다. 구체적인 사항은 추상화에 의존해야 한다(p.302).

의존성 역전 원칙은 인터페이스의 소유권에도 적용이 되는데 보통은 인터페이스가 사용하는 쪽(클라이언트)이 아닌 서버 쪽 패키지에 위치한다. 하지만 마틴 파울러의 separated interface에 따르면 추상화는 별도의 독립적인 패키지가 아니라 클라이언트가 속한 패키지에 놓아서 컴파일 시 필요한 코드가 같이 있도록 해야 한다. 함께 재사용될 필요가 없는 클래스들은 따로 분리하면 빌드 시간을 줄일 수 있다. 

 

그리고 가장 중요한 건 협력과 책임이다. 객체를 생성하는 방법에 대한 결정은 모든 책임이 자리를 잡은 후 가장 마지막에 정하는 것이 적절하다. 

 

 

// TODO

빌드 시간, 배포와 패키지의 관계..? 재배포, 재컴파일