2024/03/31(일)

Part. Spring

Tobi의 Spring 공부

 

UserDao의 다른 모든 곳에서는 인터페이스를 이용하게 만들어서 DB커넥션을 제공하는 클래스에 대한 구체적인 정보는 모두 제거가 가능했지만, 어떤 클래스 오브젝트를 사용할지를 결정하는 생성자의 코드는 제거되지 않고 남아 있다.

 

관계설정 책임의 분리

UserDao가 인터페이스뿐 아니라 구체적인 클래스까지 알아야 하는 문제가 왜 발생할까?

UserDao에는 어떤 ConnectionMaker 구현 클래스를 사용할지를 결정하는 코드가 있기 때문

UserDao안에 분리되지 않은, 또 다른 관심사항이 존재하고 있기 때문이다.

 

connectionMaker = new DConnectionMaker();

 

오브젝트 사이에 관계가 만들어지려면 만들어진 오브젝트가 있어야 한다.

직접 생성자를 호출해서 직접 오브젝트를 만드는 방법도 있지만, 외부에서 만들어 준 것을 가져오는 방법도 있다.

 

클래스 사이의 관계는 다른 클래스 이름이 나타낙 때문에 만들어지는 것이다.

오브젝트 사이의 관계는 그렇지 않다. 코드에서는 특정 클래스를 전혀 알지 못하더라도 해당 클래스가 구현한 인터페이스를 사용했다면, 그 클래스의 오브젝트를 인터페이스 타입으로 받아서 사용할 수 있다.(객체지향의 다형성 특징)

 

UserDao를 사용하는 클라이언트는 ConnectionMaker의 구현 클래스를 선택하고, 선택한 클래스의 오브젝트를 생성해서 UserDao와 연결해줄 수 있다. 기존의 UserDao에서는 생성자에게 이 책임이 있었다. 그러나 이것은 UserDao의 관심도 아니고 책임도 아니다. 다른 관심사가 함께 있으니 확장성을 떨어뜨리는 문제를 일으킨다.

 

ConnectionMaker에 대한 관심을 분리해서 클라이언트에게 떠넘기기

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

 

UserDaoTest

public class UserDaoTest {
    public static void main(String[] args) {
        ConnectionMaker connectionMaker = new NConnectionMaker();
        UserDao userDao = new UserDao(connectionMaker);
    }
}

 

UserDaoTest는 UserDao와 ConnectionMaker 구현 클래스의 런타임 오브젝트 의존 관계를 설정하는 책임을 담당해야 한다.

DAO가 아무리 많아져도 DB 접속 방법에 대한 관심은 오직 한 군데에 집중되게 할 수 있다.

 

원칙과 패턴

 

개방 폐쇠 원칙(OCP, Open-Close-Principle)

클래스나 모듈은 확장에는 열려 있어야 하고 변경에는 닫혀 있어야 한다.

UserDao는 DB 연결 방법이라는 기능을 확장하는 데는 열려 있고, UserDao 자신의 핵심 기능을 구현한 코드는 그런 변화에 영향을 받지 않고 유지할 수 있으므로 변경에는 닫혀 있다.