[토비의 스프링] 오브젝트와 의존관계 - DAO의 확장

3.DAO의 확장

데이터 엑세스 로직을 어떻게 만들 것인가, DB 연결을 어떤 방법으로 할 것인가 라는 두 개의 관심을 상하위 클래스로 분리했다.
변화의 성격이 다른 것을 분리, 서로 영향을 주지 않은 채로 각각 필요한 시점에 독립적으로 변경할 수 있게 하기 위해 추상 클래스를 만들고 이를 상속한 서브클래스에서 변화가 필요한 부분을 바꿔 쓸 수 있게 햇다.

하지만 단점이 많은, 상속이라는 방법을 사용했다는 사실이 불편하게 느껴진다.

3-1. 클래스의 분리

상속 관계도 아닌 완전히 독립적인 클래스로 만들어 보자.
DB 커넥션과 관련된 부분을 서브 클래스가 아니라, 아예 별도의 클래스를 담아보자.

SimpleConnectionMaker라는 새로운 클래스를 만들고 그 안에 DB 생성 기능을 넣는다.
각 메소드에서 매번 SimpleConnectionMaker의 오브젝트를 만들 수 있지만, 그보다 한 번만 오브젝트를 만들어 저장해두고 계속 사용하는 편이 낫다.

UserDao는 상속을 통한 방법을 쓰지 않으므로 더이상 abstract일 필요는 없다.

public class UserDao {
    private SimpleConnectionMaker simpleConnectionMaker;

    public void add(User user) throws ClassNotFoundException, SQLException {
        Connection c = simpleConnectionMaker.makeNewConnection();
        ...
    }

    public User get(String id) throws ClassNotFoundException, SQLException {
        Connection c = simpleConnectionMaker.makeNewConnection();
        ...
    }
}

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.SQLException;

public class SimpleConnectionMaker {
    public Connection makeNewConnection() throws ClassNotFoundException, SQLException {
        Class.forName("com.mysql.cj.jdbc.Driver");
        Connection c = DriverManager.getConnection("jdbc:mysql://localhost:3306/tobi", "root", "1234");
        return  c;
    }
}

기존 코드에 많은 수정을 했지만 기능에 변화를 준 것은 없다. 단지 내부 설계를 변경해서 좀 더 나은 코드로 개선했을 뿐이다.
기능에 변화가 없다는 것은 이런 리팩토링 작업의 전제이기도 하지만, 검증 내용이기도 하다.

다른 문제?

UserDao의 코드가 SimpleConnectionMaker라는 특정 클래스에 종속되기 때문에 상속을 사용했을 때처럼 UserDao 코드의 수정 없이 DB 커넥션 생성 기능을 변경할 방법이 없다.

simpleConnectionMaker = new SimpleConnectionMaker();

클래스를 분리한 경우에도 상속을 이용했을 떄와 마찬가지로 자유로운 확장이 가능하게 하려면 두 가지 문제를 해결해야한다.

1. SimpleConnectionMaker의 메소드 문제
   • 타 회사에서 DB커넥션 제공 클래스의 메소드가 달라진다면, UseDao 내의 메소드의 커넥션을 가져오는 코드를 모두 변경해야한다. 수십 수백 개의 메소드를 작성했다면 작업의 양이 너무 커진다.
   • Connection c = simpleConnectionMaker.openConnection();
2. DB커넥션을 제공하는 클래스가 어떤 것인지를 UserDao가 구체적으로 알고 있어야 한다는 점.
   • UserDao에 SimpleConnectionMaker라는 클래스 타입의 인스턴스 변수까지 정의하였으므로, 고객이 다른 클래스를 구현하면 어쩔 수 없이 UserDao 자체를 다시 수정해야한다.

근본적인 원인

UserDao가 바뀔 수 있는 정보, DB 커넥션을 가져오는 클래스에 대해 너무 많이 알고 있기 때문