1. 메서드 추출기법으로 중복되는 부분을 빼내었다.
 - 지금은 단지 메소드가 2개이지만, 나중에 이 부분이 2천개가 넘는다고 하면, 일일이 수정해야 할 것이다.
   하지만, 이렇게 메서드로 빼내면 한군데의 코드만 바꾸면 된다.
   관심의 종류에 따라 코드를 구분해놨기 때문에, 이렇게 한가지 관심에 대한 변경이 일어날 경우 그 관심이 집중되는 부분의 코드만 수정하면 된다!
상속을 통한 확장 기법

공통 부분은 getConnection을 빼낸 메서드 부분을 추상메서드로 만들고
그 메서드를 상속받은 클래스들은 자신들만의 connection을 맺을 수 있다.
문제점 : 상속의 한계점 - UserDao가 다른목적으로 이미 상속을 사용하고 있다면?
해결방안 : 상속의 한계점이 있기 때문에, 아예 커넥션 맺는 부분을 Class로 빼내서 구현하였다.
문제점 : 클래스로 빼내었지만, N사와 D사의 db커넥션 기능 확장이 불가능하게 되었다
해결방안 : 인터페이스를 도입! N사와 D사에게  커넥션 생성 인터페이스를 제공하고 각 사는 자신들에게 맞게 클래스를 구현하면된다.
문제점 : connectionMaker = new DConnectionMaker();
위 생성자의 코드는 제거되지 않고, 남아있다..필요할때마다 UserDao의 생성자 메소드를 직접 수정하라고 하지 않고는 고객에게 자유로운 DB커넥션 확장기능을 가진 UserDao를 제공할 수 없다.

해결방안 :
     public UserDao(ConnectionMaker connectionMaker) {
          this.connectionMaker = connectionMaker;
     }

UserDao를 사용하는 쪽에서 connectionMaker를 제공해줌. 이로서, UserDao는 ConnectionMaker와 느슨한 결합이 됨
이렇게 인터페이스를 도입하고 클라이언트의 도움을 얻는 방법은 상속을 사용해 비슷한 시도를 했을 경우에 비해서 훨씬 유연하다.
ConnectionMaker라는 인터페이스를 사용하기만 한다면 다른 DAO클래스에도 ConnectionMaker의 구현 클래스들을 그대로 적용할 수 있기 때문이다.
문제점 : main메서드는 테스트를 위해 만든 것이다.. 하지만, 지금은 UserDao와 ConnectionMaker를 이어주는 수고를 담당하고 있다. 단지 테스트 클래스 일 뿐인데..책임을 맡고 있으니.. 변경할 필요가 있다.

해결방안 : 분리시킬 기능을 담당할 클래스를 하나 만든다!. DaoFactory에서 userdao와 connectionmaker를 결합해주고 userdao를 제공해준다.
문제점 : UserDao뿐만이 아닌 AccountDao나 MessageDao등의 다른 DAO들이 있을 때 매번 같은 메서드를 추가해야한다. 계속 중복이 된다.

해결방안 : connection맺는 부분을 메서드로 빼내서 중복을 제거한다.
목표 : DaoFactory를 스프링에서 사용이 가능하도록 변신!

해결 : Springframework라이브러리를 추가하고 , DaoFactory가 설정정보라는 표시를 위해 @Configuration이라는 어노테이션을 적용시킨다.
그리고 오브젝트 생성 메소드라는 표시로 @Bean이라고 메서드 별로 표기한다.