DAO 2단계
문제점 - UserDao의 소스 코드 변경없이 DB 종류가 변경될 수 있고, Connection 생성 방법을 Connection Pool 또는 JNDI로 변경해야 한다면?
형기군 발표
템플릿 메소드의 가장큰 특징은 추상클래스로 생성된다.
즉 상속받아서 사용해야된다.
추상클래스 상속
1. 오버라이딩 할수도있고, 안할수도있고 -> 선택적 으로 원래 메서드를 변경할수있다. hookMethod
2. 오버라이딩 필수 (Abstract) -> 반드시 오버라이딩 해야되는것. 추상메소드(abstractMethod)
3. 오버라이딩 불가 (final) -> 템플릿 메소드(templateMethod)
Connection은 항상 되어야하기때문에 final로 지정하여 변경불가능하게 한다.
DAO 3단계
문제점 - 상속을 통해 관심이 다른기능(Connection 생성)을 분리하고, 필요에 따라 다양한 변신이 가능하도록 확장성도 부여했지만, 상속관계는 서로 다른 관심사에 대해 긴밀한 결합 관계를 가지고있다. 슈퍼클래스의 변경이 있을경우 몯느 서브클래스를 수정해야하며, UserDao외에 다른 DAO를 게속 작성해야될 경우 getConnection()메서드를 재정의한 새로운 서브클래스를 만들어야 하는 번거로움이 있다.
개선사항 - 상속관계가 아닌 완전히 독립적인 클래스로 분리하여 작성한다.
DAO 4단계
소스코드 수정 없이 DB Connection 생성 기능을 변경할 방법이 없다. DB 커넥션을 제공하는클래스의 이름이나 메소드 이름이 변경될 경우 UserDao의 코드를 수정해야한다.
개선사항 - 2개의 클래스가 서로 긴밀하게 연결되지 않도록 중간에 추상적인 느슨한 연결고리(인터페이스)를 만든다.
객체지향 기본 설계 원칙 정리
- 개방 폐쇄 원칙(OCP : Open - Closed - Principle)
클래스나 모듈은 확장에는 열려 있어야 하고 변경에는 닫혀 있어야 한다.
인터페이스를 사용해 확장 기능을 정의한 대부분의 API는 이 개방 폐쇄 원칙을 따른다.
-높은 응집도와 낮은 결합도
높은 응집도란? : 클래스나 모듈이 하나의 책임 또는 관심에만 집중되어 있다는 뜻으로 불필요하거나 직접 관련이 없는 외부의 고나심과 책임이 얽혀 있지 않으며, 하나의 공통 관심사는 한클래스에 모여 있다
낮은 결합도란? : '하나의 오브젝트가 변경이 일어날 때 관계를 맺고 있는 다른 오브젝트에 변화를 요구하는 정보'를 말한다.
- 전략 패턴(Stategy Pattern)
자신의 핵심 기능 맥락(Context)에서 필요에 따라 변경이 필요한 알고리즘(독립적인 책임으로 분리 가능한 기능)을 인터페이스를 통해 분리시키고, 이를 구현한 구현한 구체적 알고리즘 클래스를 전략적으로 바꿔 사용할 수 있는 패턴이다.
DAO 5단계
UserDao의 소스코드 변경없이 DB 커넥션 기능의 확장이 자유롭지 못하다.
개선사항 - 제3의 오브젝트를 만들어서 관리한다.
DAO 6단계
개선 - javaSE 표준 API에는 DB커넥션 생성기능을 추상화(규약)해서 일관되게 Connection을 사용할 수 있게 만들어진 javax.sql.DataSource 인터페이스를 제공한다.
DAO 7단계
문제점 - 인터페이스와 구현클래스로 분리하지 않아 다양한 데이터 엑세스 기술(JDBC, ibatis등)을 사용해 만든 DAO 사용시 일관된 메소드 호출이 불가능하며 클라이언트 입장에서 일관된 메소드 호출이 불가능하다.
개선 - DAO를 인터페이스화하여 일관된 형태로 규격을 만든다.
DAO 8단계
DAO를 동적으로 할당해주기
