토비의 스프링 3장- 템플릿

템플릿이란 → 성질이 다른 코드 중에서 변경이 거의 일어나지 않으며 일정한 패턴으로 유지되는 특성을 가진 부분을 자유롭게 변경되는 성질을 가진 부분으로부터 독립시켜서 효과적으로 활용할 수 있도록 하는 방법이다.

3.1 기존의 안좋은 코드 예시

3.1.1 예외처리를 해야함

connection에서 쿼리에 실패해도 connection을 close해야함 → 빠르게 자원을 반환하지 않으면 Connection pool의 리소스가 고갈될 수 있음.

문제는 close도 실패할 수 있음(SQLException 발생)

3.2 변하는 것과 변하지 않는 것

예외처리를 하여 괜찮아지긴 했지만, 코드 자체가 너무 복잡함 (try-catch-finally블록이 2중으로 중첩되어 있고, 모든 메서드마다 반복됨). → 이런 코드가 모든 코드에 들어가게됨.

변하지 않는, 그러나 많은 곳에서 반복되는 것들과 자꾸 변하는 코드를 잘 분리해내는 작업.

1. 처음 생각할 수 있는 방법은 변하는 부분을 메소드로 빼내는 것. (→ 변하는 부분만 빠지고, 나머지는 중복/반복되어 잘못됨)
2. 템플릿 메소드 패턴을 이용해서 분리해보자. (→ 모든 메서드마다 서브 클래스를 만들어야하는 문제)
3. 전략 패턴 (→ 잘 구현되는 듯 보였지만, 특정 구현 클래스를 알고 있어야해서 OCP에 들어맞지는 않음)
4. DI 적용을 위한 클라이언트/컨텍스트 분리 →이렇게 하면 모든 문제가 해결됨 실제로 실행할 부분을 전략패턴으로 대체하여 넘겨줌 해당부분은 익명함수로 쓸수 있을 것으로 보임

DI의 가장 중요한 개념은 제3자의 도움을 통해 두 오브젝트 사이의 유연한 관계가 설정되도록 만든다는 것

IoC 컨테이너의 도움 없이 코드 내에서 적용한 경우를 마이크로 DI라고 부름(수동 DI)

3.3 전략 패턴의 최적화

1.preparedStatement도 필요하고, 2.다른 객체를 사용하기도 함

DAO 메소드마다 새로운 전략 구현 클래스를 만들어야하는 게 문제

해결책..

로컬 클래스 → 함수 내부에 클래스로 만들어서 사용함(여기서 밖에 사용이 안되므로) → 장점이 많아 보임.. → 그러나 더 좋은 방법이 있을 것 같다

익명 내부 클래스 → 한번만 사용될 거면, 로컬 클래스로 선언하기보다도, 익명 클래스로 호출하는 부분에 넣어주면 된다.

3.4 컨텍스트와 DI

기존 context역할을 하던것을 DB종류와 무관하게 추상적으로 만들어서 JDbcCOntext로 만든다.

3.4.2 → UserDao와 jdbcContext의 클래스 레벨에서 의존관계가 결정됨 (의존 오브젝트의 구현 클래스를 변경할 수 없음...)

스프링 빈으로 DI → 인터페이스를 사용하지 않았으면 온전한 DI라고 볼 수 없음

(객체의 생성과 관계설정에 대한 제어권한을 오브젝트에서 제거하고 외부로 위임했다는 IoC라는 개념을 포괄)

JDBC대신에 JPA같은 것으로 바꾸면 전체를 바꾸게 된다.

1. 싱글톤으로 만드는 것, 2. DI필요성(JPA바꾸기 쉽게) → JdbcContext를 스프링 빈으로 등록해서 UserDao에 DI되도록 만들자

코드를 이용하는 수동 DI →싱글톤으로 만드는 것을 포기, DAO마다 JdbcContext를 가지고 있는 것 (DAO개수만큼..)

UserDao에게 DI까지 맡긴다? UserDao가 임시적으로 DI 컨테이너처럼 동작하게 만든다. → 이게 템플릿으로 발전하는 구나..

 

두 방법이 각각의 장단점이 있음

3.5 템플릿과 콜백 → 지금까지 한 것이 템플릿/콜백 패턴

전략패턴의 컨텍스트 → 템플릿( 고정된 부분)

익명 내부 클래스로 만들어지는 오브젝트 → 콜백( 변하는 부분)

템플릿/콜백을 하나의 디자인 패턴으로 보면 유용

콜백의 분리와 재활용 → 콜백에서 중복되는 부분을 추가적으로 분리함

변하는 것과 변하지 않는 것의 분리!!

콜백과 템플릿의 결합 → userDao만 사용하기 아까움 (executeSQL을 jdbcContext로 이동)

구체적인 구현과 내부의 전략 패턴, 코드에 의한 DI, 익명 내부 클래스 등의 기술은 최대한 감춰두고, 외부에는 꼭 필요한 제공하는 단순한 메소드만 노출해주는 것이 좋다!!

3.5.3 템플릿 콜백의 응용

스프링의 많은 API와 기능 → 템플릿/콜백을 적극적으로 활용

스프링에서 제공하는 템플릿/콜백 기능을 잘 사용할 수 있어야하고,

직접 필요한 곳에 템플릿/콜백을 만들어서 사용할 줄도 알아야한다.

테스트와 try/catch/finally→ ( 여기는 반복해서 읽을 필요가 있을 것 같다. 뒤의 정답을 바로 확인하기 보다는 실제로 따라가보면서 템플릿/콜백 패턴을 직접만들어보자)

중복의 제거와 템플릿/콜백 설계 ( 직접만들어보는 템플릿/콜백)

(책없이 해본게 정답.. 책은 단계적으로 나아감)

제네릭스를 이용한 콜백 인터페이스 → 템플릿/콜백에서 한단계 더 나아가서 제네릭스를 사용하여 보편적인 기능을 만드는 방법 제시

3.6 스프링의 JdbcTemplate

jdbc에 대한 소개 -update( 프로시저), quertForInt, queryForObject(자바 오브젝트로 만드는 과정이 포함 - RowMapper), query(값을 읽어오기)

테스트보완 - 네거티브 테스트부터 만들자

---

원시적인 jdbc호출에서 jdbcTemplate이 만들어지기 까지의 과정을 단계적으로 이해할 수 있게 만들어줘서 너무 좋았다.

스프링에 대한 이해뿐만 아니라, 프로그래밍에 대한 이해도도 늘어난 것 같다. 매우 좋은 챕터이다.