토비의 스프링 3.1 1장(vol.1)

초난감 코드

public class UserDao {
    public void add(User user) throws Exception {
        Connection c = DriverManager.getConnection(...);
        PreparedStatement ps = c.prepareStatement(...);
        ps.executeUpdate();
        ps.close();
        c.close();
    }
    
    public void get(String id) throws Exception {
        Connection c = DriverManager.getConnection(...);
        ...
    }
}

위의 코드는 치명적인 문제점들이 있다.

1. DB에 연결하는 코드 getConnection() 이 반복된다
2. DB가 바뀌면 모든 DAO를 바꿔야하는 변경에 취약한 문제가 있다
3. 비즈니스 로직과 DB 연결 부분이 섞여있다.

관심사의 분리

위와 같은 문제를 해결하기 위해 각 역할을 나눠야한다!

public abstract class UserDao {
    protected abstract Connection getConnection();
}

• DB 연결 부분을 따로 뺐다

public class NUserDao extends UserDao {
    protected Connection getConnection() {
        return DriverManager.getConnection(...);
    }
}

• 이젠 DB 변경 시 하위 클래스만 수정하면 된다!
• 하지만 아직 상속에 의존하고 있다

템플릿 메소드 패턴

• 위의 구조는 템플릿 메소드로 표현할 수 있다
  • 상위 클래스 : 알고리즘 구조 정의 역할
  • 하위 클래스 : 일부만 구현
• 템플릿 메소드의 한계
  • 강한 결합
  • 런타임 변경이 어렵다

인터페이스 도입

그래서 더 좋은 방식을 쓰기 위해 상속 대신 인터페이스를 사용한다!

public interface ConnectionMaker {
    Connection makeConenction();
}

인터페이스로 분리하고

public class DConnectionMaker implements ConectionMaker {
    public Connection makeConnection() {
        return DriverManager.getConnection(...);
    }
}

위와 같이 구현

public class UserDao {
    private ConnectionMaker connectionMaker;
    
    public UserDao(ConnectionMaker connectionMaker) {
        this.connectionMaker = connectionMaker;
    }
}

→ 이렇게 작성하면 UserDao는 구현이 아닌, 인터페이스에 의존할 수 있게 된다

의존관계 주입 (DI)

그런데, ConnectionMaker를 누가 넣어주게 될까?

UserDao dao = new UserDao(new DConnectionMaker());

→ 객체가 직접 생성하지 않고, 외부에서 넣어준다

팩토리 도입

public class DaoFactory {
    public UserDao userDao() {
        return new UserDao(new DConnectionMaker());
    } 
}

팩토리를 통해 “객체 생성”과 “사용”을 분리시킨다

IoC (제어의 역전)

기존에는 개발자가 직접 객체를 생성했다면,

이제는 팩토리가 대신 생성하게 시킨다. 즉, 객체의 생성/관리 권한이 외부로 넘어간다!

스프링으로 연결

이러한 개념을 자동으로 해주는게 바로, “스프링 컨테이너”다!

스프링은 “객체 생성”, “의존관계 주입”, “라이프사이클 관리” 의 역할을 수행한다.