개방폐쇠의 원칙 다시한번.
코드에서 어떤 부분을 변경을통해 기능이 다양해지고, 어떤 부분은 고정되어 변하지 않는 성질이 있음
변화의 특성이 다른 부분을 구분해주고 각각 다른 목적과
다른 이유에 의해 다른 시점에서 독립적으로 변경될 수 있는 효율적구조
하지만
템플릿은 변경이 거의 일어나지 않는다.
일정한 패턴으로 유지되는 특성을 가진 부분을 자유롭게 변경되는 성질을 가진부분으로 독립하고
효과적으로 활용할 수 있다.
Connection / PreparedStatement 리소스를 가져와서 사용
하지만 예외가 발생하면?
####JDBC 조회 기능의 예외처리
위에 코드는 너무 중복코드에 복잡함..
개방폐쇠의 원칙을 적용?
하지만 조금 다르게 접근...
변하지않는 부분을 변하는 부분과 분리해보자..
변하는 부분 메소드 추출 첫번째.
뭔가 이상해 짐 다시..!
상속을 통해 기능을 확장!
변하지 않는 부분을 슈퍼클래스로
변하는 부분은 추상 메소드로.
템플릿 메소드 패턴의 상속을 통한 단점이 고스란히 드러남
deleteAll() 메소드에서 변하지않는 부분이 contextMethod()
두번째 작업이 외부기능이 바로 전략패턴에서 말하는 전략.
문제 DeleteAllStatement를 직접 알고 있으면 전략패턴 OCP에 잘맞는다고 볼 수 없다.
문제점
DAO 클래스를 만들 때 마다 StatementStartegy 구현 클래스를 만들어야 된다.
User 같은 부가정조바 잇는경우 생성자와 인스턴스 변수를 만들어야됨.
StatementStrategy UserDao 안 내부 클래스로 정의
흠.. 별로 좋은 방법은 아닌거같은데...
모든 DAO 에서 사용 할 수있게
인터페이스가 아닌이유는 자체적이고 독립적인 JDBC 컨텍스트 를 제공해주므로
서비스 오브젝트 의미이기때문에 구현 방법이 바뀔 이유가 없기 때문이다.
DI 인터페이스 사이에 둬서 클래스 레벨에서는 의존관계가 고정되지 않고
런타임 시에 의존할 오브젝트와의 관계를 동적으로 주입해 준다.
하지만 넓게보면 객체 생성과 관계설정에 대한 제어권한을
오브젝트에서 제거하고 외부로 위임했다는 Ioc 개념을 포괄함.
여러가지 설명이있지만 패스.
내부에 직접 DI
자신이 사용할 오브젝트를 만들고 초기화하는 전통적인 방법
전략 패턴의 컨텍스트를 템플릿 / 익명 내부 클래스로 만들어지는 오브젝트를 콜백이라 부름
템블릿 : 고정된 작업 흐름을 가진 코드를 재사용
콜백: 탬플릿 안에서 호출되는 목적으로 만들어진 오브젝트
템플릿/콜백의 특징
코드가 복잡해지는 단점..
한 애플리케이션 안에서 동시에 여러종류가 만들어진다면
템플릿 / 콜백 패턴을 적용해 본다.
코드다.
스프링은 다양한 JDBC 템플릿/콜백 제공
기본 템플릿은 JdbcTemplate
JDBC PreparedStatementCreator 인터페이스의 createPreparedStatement() 메소드
콜백을 받는 update()
get() 메소드에 JDBC 적용
기능 정의와 테스트 작성
DI를 위한 코드 정리