1.9 정리

1. 책임이 다른 코드를 분리하여 두 개의 클래스를 만듦(관심사의 분리, 리팩토링)
2. 바뀔 수 있는 쪽의 클래스는 인터페이스를 구현하고, 다른 클래스는 인터페이스를 통해 접근(전략 패턴)
3. 자신의 책임 자체가 변경되는 경우 외에는 불필요한 변화가 발생하지 않도록 막아주고, 자신이 사용하는 외부 오브젝트의 기능은 자유롭게 확장하거나 변경할 수 있도록 만듦(개방 폐쇄 원칙)
4. 한쪽의 기능 변화가 다른 쪽은 기능 변경을 요구하지 않아도 되며(낮은 결합도), 자신의 책임과 관심사에만 순수하게 집중(높은 응집도)할 수 있게 됨
5. 오브젝트가 생성되고 여타 오브젝트와 관계를 맺는 작업의 제어권을 별도의 오브젝트 팩토리 또는 IoC 컨테이너로 넘겨서 오브젝트가 자신이 사용할 대상의 생성이나 선택에 관한 책임으로부터 자유롭게 만들어 줌(제어의 역전/IoC)
6. 전통적 싱글톤 패턴 구현 방식의 단점을 극복할 수 있도록 설계된 컨테이너를 활용(싱글톤 레지스트리)
7. 설계 시점과 코드에는 클래스와 인터페이스 사이의 느슨한 의존 관계만 만들어놓고, 런타임 시 실제 사용할 구체적인 오브젝트를 제 3자(DI 컨테이너)의 도움으로 주입받아 다이내믹한 의존관계를 갖게 해줌(의존관계 주입/DI)
8. 의존 오브젝트를 주입하는 방법(생성자 주입과 수정자 주입)
9. XML을 이용하여 DI 설정정보를 생성, 일반 값을 외부에서 설정하여 런타임 시에 주입(XML 설정)