1장. 오브젝트와 의존관계
일러두기
- 토비의스프링3.1 Vol.1을 읽고 정리한 글입니다.
- 책을 이미 읽으신 분이 빠르게 훑으며 복습하는 용도로 보시면 좋을 것 같습니다.
- 임의로 핵심만 간추렸습니다. 책과 설명하는 순서가 바뀌거나 장/절 목차 이름이 바뀌거나 아예 빠진 내용이 많습니다.
1 XML을 이용한 설정
- DaoFactory 자바 코드로 설정했던 DI를 위한 오브젝트 의존관계 정보를 XML 파일로 옮겨보자.
XML 설정의 장점
- 단순한 텍스트 파일이기 때문에 다루기 쉽고 쉽게 이해할 수 있다
- 컴파일과 같은 별도의 빌드 작업이 필요없다
- 환경이 달라져서 오브젝트의 관계가 바뀌어야 할 때 빠르게 바꿀 수 있다
- 정해진 포맷을 지켰는지 손쉽게 확인이 가능하다
- 스키마, DTD를 통해
DI 정보를 담는 XML 파일
<beans>를 루트 엘리먼트로 사용- @Configuration
- 여러 개의
<bean>을 정의할 수 있음- @Bean
- 빈의 이름
- 빈의 클래스
- 빈의 의존 오브젝트
- 생략 가능
XML 설정으로 전환하기
애플리케이션 컨텍스트에 XML 설정 적용하기
DataSource 인터페이스로 변경
DataSource
- 우리가 만든 ConnectionMaker의 기능을 지원하는 표준 인터페이스
ConnectionMaker -> DataSource
자바 코드로 DI 설정하기
XML로 DI 설정하기
2 정리
- 먼저 책임이 다른 코드를 분리해서 두 개의 클래스로 만들었다(관심사의 분리, 리팩토링).
- 그중에서 바뀔 수 있는 쪽의 클래스는 인터페이스를 구현하도록 하고, 다른 클래스에서 인 터페이스를 통해서만 접근하도록 만들었다. 이렇게 해서 인터페이스를 정의한 쪽의 구현 방 법이 달라져 클래스가 바뀌더라도 그 기능을 사용하는 클래스의 코드는 같이 수정할 필요가 없도록 만들었다(전략 패턴).
- 이를 통해 자신의 책임 자체가 변경되는 경우 외에는 불필요한 변화가 발생하지 않도록 막 아주고, 자신이 사용하는 외부 오브젝트의 기능은 자유롭게 확장하거나 변경할 수 있게 만 들었다(개방 폐쇄 원칙).
- 결국 한쪽의 기능 변화가 다른 쪽의 변경을 요구하지 않아도 되게 했고(낮은 결합도), 자신의 책임과 관심사에만 순수하게 집중하는(높은 응집도) 깔끔한 코드를 만들 수 있었다.
- 오브젝트가 생성되고 여타 오브젝트와 관계를 맺는 작업의 제어권을 별도의 오브젝트 팩토 리를 만들어 넘겼다. 또는 오브젝트 팩토리의 기능을 일반화한 IoC 컨테이너로 넘겨서 오브 젝트가 자신이 사용할 대상의 생성이나 선택에 관한 책임으로부터 자유롭게 만들어줬다(제어의 역전, IoC)
- 전통적인 싱글톤 패턴 구현 방식의 단점을 살펴보고 서버에서 사용되는 서비스 오브젝트 로서의 장점을 살릴 수 있는 싱글톤을 사용하면서도 싱글톤 패턴의 단점을 극복할 수 있도 록 설계된 컨테이너를 활용하는 방법에 대해 알아봤다(싱글톤 레지스트리).
- 설계 시점과 코드에는 클래스와 인터페이스 사이의 느슨한 의존관계만 만들어놓고, 런타임 시에 실제 사용할 구체적인 의존 오브젝트를 제3자의 컨테이너)의 도움으로 주입받아서 다이 내믹한 의존관계를 갖게 해주는 IoC의 특별한 케이스를 알이봤다(의존관계 주입/DI).
- 의존 오브젝트를 주입할 때 생성자를 이용하는 방법과 수정자 메소드를 이용하는 방법을 알 아봤다(생성자 주입과 수정자 주입).
- 마지막으로, XML을 이용해 DI 설정정보를 만드는 방법과 의존 오브젝트가 아닌 일반 값 을 외부에서 설정해서 런타임 시에 주입하는 방법을 알아봤다(XML 설정).
3 개선된 초난감 DAO
UserDao
자바 코드로 DI하는 버전
xml로 DI하는 버전
Backend 취준생