토비의 스프링 요약 3장 - 템플릿 (2)

[ 3.4 컨텍스트와 DI ]

  • 예제에서 jdbc를 활용하고 예외를 처리하는 부분은 공통적으로 사용 할 수 있음
  • 위 context에 해당하는 부분을 따로 독립 시켜 다른곳에도 활용해 보자.
  • 분리와 동시에 전략을 DI받는 형태로 바뀜
  • 스프링 Bean설정은 오브젝트 레벨의 의존관계에 따라 정의됨

-> text-applicationContext.xml 수정.

<bean id = "userDao" ...>
	<property name = "dataSource" ref="dataSource"/>
	<property name = "jdbcContext" ref="jdbcContext"/>
</bean>

<bean id= jdbcContext" class="..."></bean>

지금까지와는 다른 DI

  • 지금까지와는 다르게 인터페이스를 사용하지않고 DI를 적용함
  • 기존 : 인터페이스를 통해 직접 클래스에 접근하지 않고, 설정을 변경하여 사용

스프링 빈으로 DI

  • DI 란?
    • 인터페이스를 사이에 둬서 클래스 레벵레서 고정되지않게
    • 런타임에 의존할 오브젝트를 동적으로 결정.
  • 스프링의 DI는?
    • 객체의 생성과 관계, 제어권한을 오브젝터에서 제거하고 외부에서 위임
    • IoC라는 개넘을 충실히 수행
    • 인터페이스를 사용하지 않음 - 강하게 연결되어있음
  • 왜쓰는가? (언제 쓰면 좋은가?)
    • 싱글톤으로 관리되어 여러 오브젝트에서 공유해서 사용
    • 다른 bean 에 의존하고 있어서 IoC의 대상으로서 빈에 등록되어야함
    • 단, 이런 구성은 최후에 고려하자.

수동으로 DI

  • 싱글톤 포기 -> DAO마다 생성
  • 자동생성,초기화 -> 생성과 초기화를 직접 담당한다
  • DataSource에서 DI받는것을 못함 -> 다이나믹하게 주입

[ 3.5 템플릿과 콜백 ]

  • 템플릿/콜백 패턴
    • 전락 패턴에서 익명 내부 클래스를 활용한 방식
    • 전략 패턴의 context : 템플릿, 익명 내부 클래스로 만들어지는 오브젝트를 콜백이라고 부름.
  • 코드를 재사용하는 목적이 강함!

특징

  • 보통 단일 메소드 인터페이스를 사용함
    • 특정기능을 위해 한번 호출되는 경우가 많음
    • 하나의 메소드를 가진 익명 내부 클래스로 구현됨
  • 보통 파라미터가 있음
    • 컨텍스트 정보를 전달받을 때 사용됨
  • 절차 : 그림 3-7 참조
    • 클라이언트에서 CallBack을 생성하여 DI ( 템플릿에게 줌)
    • 템플릿은 CallBack 기능 수행 전에 해야할 고정된 코드 수행.
    • CallBack함수 호출되고, Client 쪽에서 받은 Callback이 수행된다.
    • 작업결과를 템플릿이 받고 수행 후에 하는 고정된 코드를 수행한다.
    • 결과를 Client에게 전달한다.
  • 하지만.. 익명 내부 클래스를 사용하기 때문에 코드 작성불편, 가독성이 떨어짐.

콜백의 분리와 재활용

#