토비의 스프링 VOL.1 CH1

개념 정리

---

오브젝트에 대한 설계와 구현한 코드는 변한다.

• 변화가 생길 때 수정할 코드의 양을 줄여야 한다.
• 분리와 확장을 고려한 설계가 필요하다.
• 관심이 같은 것끼리 하나의 객체로 모아 관심사의 분리해야 한다.
• 개방 폐쇄 원칙 : 확장에는 열려있어야 하고 변경에는 닫혀있어야 한다.
• 응집도는 높이고 결합도는 낮춰야 한다.

제어의 역전(Inversion Of Control)

• 오브젝트가 자신이 사용할 오브젝트를 생성하거나 선택하지 않는다. 다른 대상에게 위임한다.
• 스프링에서는 애플리케이션 컨텍스트를 이용해서 빈의 생성과 관계설정 등의 제어를 한다.
• 빈 : 스프링이 제어권을 가지고 직접 만들고 관계를 부여하는 오브젝트
• 라이브러리 ? 프레임워크 ? : 라이브러리는 애플리케이션의 흐름을 개발자가 직접 제어한다. 하지만 프레임워크는 프레임워크가 흐름을 주도하는 중에 개발자가 만든 코드 사용한다.(IoC)

의존 관계 주입(Dependency Injection)

• 의존관계 : A가 B에 의존하고 있다고 할 때, B에 변경이 생기면 A에 영향을 준다는 것이다.
• 오브젝트의 레퍼런스를 외부로부터 주입받고 이를 통해 여타 오브젝트와 관계가 만들어진다.
• 클래스 모델이나 코드에는 런타임 시점의 의존관계가 드러나지 않는다.
• 런타임 시점의 의존관계는 컨테이너나 팩토리 같은 3의 존재가 결정한다.
• 의존관계는 사용할 오브젝트에 대한 레퍼런스를 외부에서 제공해줌으로써 만들어진다.

의존관계 주입 방법

• 생성자를 이용한 의존관계 주입
• 수정자 메소드(setter)를 이용한 의존관계 주입
• 일반 메소드를 이용한 의존관계 주입

의존관계 검색(Dependency LookUp)

• 자신이 필요로하는 의존 오브젝트를 능동적으로 찾는다.
• 의존관계를 맺을 오브젝트를 스스로 컨테이너에 요청
• ex) getBean

DI와 DL의 차이

• 의존관계 검색 방식에서는 검색하는 오브젝트는 자신이 스프링 빈일 필요가 없다.
• 의존관계 주입에서는 의존성이 주입되는 객체와 의존성을 주입받는 객체 둘 다 빈이어야한다. (인터페이스 타입의 파라미터)

싱글톤

• 애플리케이션 컨텍스트는 싱글톤을 저장하고 관리하는 싱글톤 레지스트리다.
• 스프링은 기본적으로 내부에서 생성하는 빈 오브젝트를 싱글톤으로 만듣다.
• 멀티스레드 환경에서 싱글톤을 사용하면 오브젝트는 상태정보를 내부에 갖고 있지 않는 무상태 방식으로 만들어져야 한다.

UserDao 예제

---

UserDao의 관심사

1. DB 연결을 위한 Connection 가져오기 (DB 연결)
2. Statement를 만들고 실행하기
3. Statement와 Connection을 닫아 리소스를 돌려주기

복잡한 코드를 정리해보자

1. 중복 코드를 메소드로 분리한다. (메소드 추출 기법)

   • db 연결을 할때마다 Connection을 생성하는 코드는 중복된다.
   • Connection 생성하는 코드를 getConntection 메소드로 분리

2. 상속을 통한 확장

   • 위에서 분리하 getConntection 메소드를 추상 메소드로 만든다.
   • 추상 메소드가 있는 클래스를 상속하는 클래스를 만들고 추상 메소드를 구현한다.
   • 템플릿 메소드 패턴 : 슈퍼클래스에 기본적인 로직의 흐름을 만들고 그 기능의 일부를 추상 메소드나 protected 메소드 등으로 만들어 서브클레스에서 필요에 맞게 구현해서 사용하는 방법
   • 팩토리 메소드 패턴 : 서브클레스에서 구체적인 오브젝트 생성 방법을 결정하게 하는 방법. 어떤 Connection을 return할지 getConnection 메소드에서 결정

3. 하지만 상속을 통한 확장을 하면

   • 다중상속이 불가하다.
   • 상속은 부모와 자식이 연결되어있다. (Tight Coupling)
   • 다른 클래스에 적용하기 어렵다.

4. Connection을 가져오는 부분을 클래스로 분리

   • UserDao는 커넥션 클래스의 메소드를 알고 있어야한다.
   • UserDao가 커넥션 클래스를 알아야한다.

5. Connection을 가져오는 클래스를 인터페이스로 바꾼다.

   • 인터페이스를 통해 접근하게하면 실제 구현 클래스르 바꿔도 신경쓰지 않아도 된다.
   • 하지만 커넥션을 가져오는 것을 인터페이스로 분리해도 처음 한번은 new로 인터페이스를 구현한 클래스를 생성해야하기 떄문에 실제 구현 클래스를 알아야 한다.

6. 실제 클래스를 구현하고 관계를 연결해주는 제 3의 클래스 생성 (Factory)

   • Factory 클래스에서 Connection의 구현 객체를 만든 뒤 이를 UserDao를 new할 때 생성자 파라미터로 전달.

Reference

---

책 : 토비의 스프링 3.1 Vol.1 스프링의 이해와 원리 (저 이일민)