1단계에서 메소드 추출을 이용했다.

만약 이 UserDao클래스가 인기가 많아 N사와 D사에 판매를 하는 경우
N사와 D사의 경우 각각 다른 DB을 쓰고 연결관리를 한다는 가정하에선

기존에 만들어 놓은 UserDao방식은 확장성에서 상당히 비효율적이다. 안에 메인클래스를 수정해야 함은 당연지사고 내가 고생해서 만든 UserDao클래스 극비문서를 남에게 보여줘야 한다는 문제점도 있다.

그래서 이번 단계에서는 내가 만든 UserDao클래스를 보호하면서 각기 다른 회사에 맞는 커넥션을 제공해줄수 있는 리팩토링이다.

여기에서 쓰이는 패턴은 템플릿 메소드 패턴(template method pattern:슈퍼클래스에 기본적인 로직의 흐름을 만들고 , 그 기능의 일부를 추상 메소드나 오버라이딩이 가능한 protected 메소드등으로 만든뒤 필요한 서브클래스에서 이러한 메소드를 필요에 맞게 구현해서 사용하도록 하는 방법)

그리고 서브클래스에서 구체적인 오브젝트 생성방법을 결정하게 하는 것을 팩토리 메소드 패턴(factory method pattern)이라고도 한다. 

그럼 구체적인 예로는 다음과 같다.

1.클래스를 추상클래스로 변환한다.
public abstract class UserDao {
Connection c = getConnection();
.....

public abstract Connection getConnection() throws ClassNotFoundException,SQLException;

}
2.N사와 D사는 제공되어진 추상클래스에 제공해서 getConnection() 부분만 따로 정의를 한다.

public class DUserDao extends UserDao {

@Override
public Connection getConnection() throws ClassNotFoundException,
SQLException {
//N 사 DB connection 생성코드 작성
return 만들어진 Connection;
}

}

public class NUserDao extends UserDao {

@Override
public Connection getConnection() throws ClassNotFoundException,
SQLException {
//N 사 DB connection 생성코드 작성
return 만들어진 Connection;
}

}

하지만 여기에서 큰 문제점이 있다.

자바는 다중상속이 금지되어있다.

그래서 만약 N사나 D사의 구현클래스가 다른 클래스를 이미 상속받았다면 우찌할텐가..

그래서 다음단계에서 "DAO의 확장" 한단계 더 리팩토링을 해보자.

+ Recent posts