[Spring] 오브젝트 팩토리

👉 클라이언트인 UserDaoTest에서 ConnectionMaker 구현 클래스를 사용할지를 결정하는 기능을 갖고 있습니다.

하지만 UserDaoTest는 UserDao의 기능이 잘 동작하는지 테스트를 위한 클래스입니다.

 

그렇기 때문에 UserDaoTest에 있는 Connection Maker 구현 부분을 분리해야합니다.

 

💡 팩토리

 

분리시킬 기능을 담당할 클래스를 만들기 위해,

이 클래스는 객체의 생성 방법을 결정하고 그렇게 만들어진 오브젝트를 돌려주는 것인데,

이 클래스를 팩토리라고 부릅니다.

 

주의해야할 점은 추상 팩토리 패턴이나 팩토리 메소드 패턴과는 다르다는 것을 인지해야합니다.

 

이제 팩토리 클래스의 역할을 하는 DaoFactory 클래스를 만들어보겠습니다.

 

DaoFactory 클래스

public class DaoFactory {
    public UserDao userDao(){
        ConnectionMaker connectionMaker = new NConnectionMaker();
        UserDao userDao = new UserDao(connectionMaker);
        return userDao
    }
}

 

 이렇게 각각이 자신의 책임에만 충실하도록 역할에 따라 분리하는 작업을 하였으며,

 DaoFactory의 소스만 공개하고 UserDao의 소스는 안전하게 보존 할 수 있습니다.

 

 UserDaoTest에서는 DaoFactory 안의 userDao만 불러주면 됩니다.

public class UserDaoTest {
    public static void main(String[] args) throws ClassNotFoundException, SQLException {
        UserDao dao = new DaoFactory().userDao();
        //...생략
    }
}

UserDao, ConnectionMaker : 애플리케이션의 핵심적인 데이터 로직과 기술 로직을 담당

DaoFactory : 애플리케이션의 오브젝트들을 구성하고 그 관계를 정의하는 책임을 담당

 

 

🧾 정리

UserDao와 DaoFactory에 제어의 역전이 적용되어 있습니다.

 

💡 제어의 역전이란?

참고: https://withseungryu.tistory.com/61?category=880574

[Spring] 스프링의 심장부 - IoC (제어의 역전)

 

원래 ConnectionMaker의 구현 클래스를 결정하고 오브젝트를 만드는 제어권은 UserDao에게 있었는데,

DaoFactory에게 권한을 넘겨주면서 UserDao는 능동적에서 수동적인 존재로 변경되었습니다.

또한 UserDao와 ConnectionMaker의 구현체를 생성하는 책임도 DaoFactory가 맡고 있습니다.

 

즉, DaoFactory를 도입했던 과정이 바로 IoC를 적용하는 작업이었다고 볼 수 있습니다.

 

이러한 DaoFactory는 오브젝트 수준의 가장 단순한 IoC 컨테이너, IoC 프레임워크라고 불릴 수 있습니다.

 

참고 문서 : 

토비의 스프링3 (이일민)