DB Connection의 독립

UserDao를 한단계 더 분리한다면 DB커녁션 생성방식을 임의로 언제든 적용할 수 있습니다.

물론 어떤 소스라도 그 작업은 가능하지만, 수정할 일이 생겨서 진행하고 싶을 때 간단하게 DB부분만을 수정할 수 있도록 해주기 때문에, 유지보수 및 보안에 큰 장점을 갖고 있습니다.

UserDao에서 메소드 코드 제거 후 getConnection()을 추상 메소드로 만듭니다.

추상메소드는 메소드내에 아무것도 진행되는 것 즉 메소드 코드는 없지만 메소드 자체는 존재합니다.

따라서 add(), get() 메소드에서 getConnection()을 호출하는 코드를 그대로 사용할 수 있게 되는 것입니다.

기존에는 같은 클래스에 다른 메소드로 분리했던 DB Connection 연결이라는 관심을 이번에는 상속을 통해 서브클래스로 분리해버리는 것입니다.

다음과 같이 리팩토링하면 되겠습니다^^

public abstract class UserDao {

public void add(User User) throws ClassNotFoundException, SQLException {

Connection cnn = getConnection() ;

}

public void add(String id) throws ClassNotFoundException, SQLException {

Connection cnn = getConnection() ;

}

public abstract Connection getConnection() throws ClassNotFoundException, SQLException;

}    //end

=======================================================================================

public class KorUserDao extends UserDao {

public Connection getConnection() throws ClassNotFoundException, SQLException {

}

}    //end

public class JpnUserDao extends UserDao{

public Connection getConnection() throws ClassNotFoundException, SQLException{

}

}    //end

KorUserDao, JpnUserDao 클래스는 UserDao를 상속함으로써, UserDao 코드를 수정할 필요 없이 DB에 연결할 수 있게 되었습니다.

UserDao가 확장됨으로써 편의성을 제공해주고 있습니다.^^ 작업의 편의와 유지보수가 정말 간단하게 해결된 것을 느낄 수 있을 겁니다.

이와 같은 방법을 사용하는 것을 디자인 패턴에서 템플릿 메소드 패턴(Template Method Pattern) 이라고 명명합니다. ("디자인 패턴"이라는 말과 "템플릿 메소드 패턴"이 무엇인지는 포스팅 가장 끝에 정리해보도록 하겠습니다.)

스프링에서는 TMP 템플릿 메소드 패튼을 자주 사용합니다. 간단히 말하면 서브클래스에서 구체적인 오브젝트 생성방법을 결정하도록 유도하는 것입니다.

서브클래스에서 구현하는 getConnection()은 JDBC가 정의한 Connection 인터페이스를 구현한 Connection 오브젝트를 각각의 알고리즘을 통해 생성합니다.

즉, 서브클래스에서 사용하는 것은 자유롭지만 그 방법은 수퍼클래스에서 정해놓게 됩니다.  위와 같이 사용하게 되면 Connection 인터페이스의 메소드를 자유롭게 사용할 수 있게되겠네요.

Connection Object를 생성하는 방법은 크게 두가지로 말할 수 있겠습니다.

첫번째는 서버의 DB Connection Pool에서 가져오는 방법이고, 두번째는 Driver를 직접 이용하는 것입니다.

 디자인패턴

어플리케이션 설계시 특정 상황에서 빈번히 발생하는 문제를 해결하기 위해 존재합니다.

모든 패턴에는 각각의 이름이 있어서 자주 사용되는 패턴을 적용하려 할 떄 간단히 그 패턴의 이름을 말해줌으로써 

전체 설계의 의도와 목적 및 목표를 공유할 수 있게 되는데요. 모든 프로젝트가 대부분 팀으로 진행하기 때문에 

어떻게 코딩할지를 명확히 할 수 있죠^^

디자인 패턴이라는 주로 객체지향에 관한 것입니다. 패턴의 구조는 대부분 비슷한데, 기본적으로 객체지향을 

추구하기 때문입니다. 대표적인 방법이 확장! 상속! 입니다. 객체지향의 다형성과도 일맥상통하는 개념이죠.

확장성을 추구하는 방법은 두 가지 구조를 갖습니다. 하나는 클래스 상속, 다른 하나는 오브젝트 합성이라는 것인데

클래스 상속은 익숙하지만, 오브젝트 합성이라는 말은 생소하네요.

패턴의 목적과 그 의도가 분명히 존재하겠죠? 해결하려는 상황, 문제, 솔류션 구조와 역할 등에 따른 의도를 분명히

인지하고 있어야만 패턴이라는 것을 사용할 수 있을 것입니다.

자바 개발자라면 필히 알아야 할 부분이죠.

 템플릿 메소드 패턴

수퍼클래스를 확장할 때 사용되는 대표적인 방법입니다. 수퍼클래스라는 것은 절대로 변하지 않습니다. 

절대로 변하지 않는 기능은 수퍼클래스에 만들어두고 상황에 따라 변경해야 하는 기능은 서브클래스에 만들어서

수퍼클래스의 메소드를 오버라이딩해서 사용한다는 개념입니다.

서브클래스에서는 추상 메소드를 구현하거나, 선택적으로 오버라이드 할 수 있도록 만들어둔 hook메소드를 오버라이드하는 것으로 그 기능을 할 수 있습니다.

 팩토리 메소드 패턴

템플릿 메소드 패턴과 마찬가지로 상속을 통한 확장기능을 구현하는 패턴이기 때문에 구조도 상당히 비슷합니다.

수퍼클래스 코드에서는 서브클래스에서 구현할 메소드를 호출해서 필요한 타입의 오브젝트를 가져와 사용하는 것입니다.

주로 인터페이스 타입으로 오브젝트를 리턴하기 때문에 서브클래스에서 정확한 클래스의 오브젝트를 만들어 리턴할지는 수퍼클래스에서는 알지 못합니다. 알 필요도 없구요.

즉, 

서브클래스에서 오브젝트 생성 방법과 클래스를 결정할 수 있도록 미리 정의해둔 메소드를 팩토리 메소드라고 하는 것입니다.

상속을 이용한다는 것은 분명히 단점도 존재하는데요. 상속 자체는 간단해 보이지만, 한계점이 따르게 되기 때문입니다.

UserDao가 다른 목적을 위해 상속을 사용하는 경우가 그렇습니다. 자바는 다중상속을 허용하지 않죠? 단지, 커넥션 객체를 불러오는 방법을 분리하기 위해 상속구조로 만들어버리면 추후에 다른 목적으로 UserDao에 상속을 구현해주는 것이 사실 불가능합니다.(개념상 말이죠)

 정리하겠습니다.

서브클래스는 수퍼클래스의 기능을 사용합니다. 즉 오버라이드힙니다. 서브클래스는 아무리 자유롭게 변경해도 상관없지만, 수퍼클래스를 변경해버리면 상속한 모든 클래스를 변경해주어야겠죠. 어쩌면 개발자체를 다시 진행해야하는 수도 있습니다. 그만큼 수퍼클래스에 정의한 내용이 중요하다는 의미겠죠?

위의 예제를 통해 살펴봤듯이 DB Connection을 생성하는 코드를 다른 DAO클래스에 적용할수 없다는 것도 큰 문제점이 될 수 있습니다. 애시당초 이 부분을 생각하면서 코딩을 해야합니다.