From: 도메인 주도 설계

  • 다른 객체를 생성하는 책임을 갖는 프로그램 요소를 팩토리라 부른다.

모든 객체지향 언어에서 객체 생성 메커니즘(이를테면, 자바와 C++의 생성자, 스몰토크의 인스턴스 생성 클래스 메서드)을 제공하지만 다른 객체와 분리된 좀더 추상적인 생성 메커니즘이 필요하다. 자신의 책임이 다른 객체를 생성하는 것인 프로그램 요소를 FACTORY라 한다.

한 객체의 인터페이스가 자신의 구현을 캡슐화해서 객체의 동작방식을 알아야 할 필요 없이 클라이언트가 해당 객체의 행위를 이용할 수 있게 해주듯이 FACTORY는 복잡한 객체나 AGGREGATE를 생성하는 데 필요한 지식을 캡슐화한다. FACTORY는 클라이언트의 목적과 생성된 객체의 추상적인 관점을 반영하는 인터페이스를 제공한다. 1

  • 팩토리 분리에 대하여

대신 우리는 그러한 각 부품을 조립해줄 다른 뭔가를 활용한다. 그것은 아마도 수리공이거나 산업용 로봇일 것이다. 로봇과 사람은 모두 실제로 자신이 조립하는 엔진보다 더 복잡하다. 부품을 조립하는 일은 축을 회전시키는 것과는 전혀 상관이 없다. 차를 조립하는 기능은 자동차를 생산하는 동안에나 필요할 뿐 운전할 때는 로봇이나 조립공이 필요하지 않다. 자동차를 조립하고 운전하는 일은 결코 같은 시간에 할 수 없으므로 이러한 기능이 모두 동일한 메커니즘에 결합돼 있는 것은 아무런 가치가 없다. 마찬가지로 복잡한 복합 객체를 조립하는 일은 조립이 완료됐을 때 해당 객체가 하는 일과 가장 관련성이 적은 일이다.

그러나 애플리케이션에서 그와 같은 책임을 클라이언트 객체로 옮긴다면 문제가 훨씬 더 나빠진다. 클라이언트는 어떤 작업이 이뤄져야 하는지 알고 있으며, 도메인 객체에 의존해 필요한 연산을 수행한다. 클라이언트에서 자신이 원하는 도메인 객체를 직접 조립해야 한다면 클라이언트는 도메인 객체의 내부구조를 어느 정도 알고 있어야 한다. 도메인 객체의 각 구성요소의 관계에 적용되는 모든 불변식을 이행하려면 클라이언트에서 해당 객체의 규칙을 어느 정도 알아야 한다. 이렇게 되면 생성자를 호출하는 것만으로도 생성 중인 객체의 구상 클래스와 클라이언트가 결합된다. 클라이언트를 변경하지 않고는 도메인 객체의 구현을 변경할 수 없으며, 이로써 리팩터링이 더 힘들어진다. 2

함께 읽기

  • [[/pattern/abstract-factory]]
  • [[/pattern/builder]]
  • [[/pattern/factory-method]]
  • [[/pattern/static-factory-method]]

참고문헌

  • 도메인 주도 설계 / 에릭 에반스 저 / 이대엽 역 / 위키북스 / 2011년 07월 21일 / 원제 : Domain-Driven Design

주석

  1. 도메인 주도 설계. 6장. 142쪽. 

  2. 도메인 주도 설계. 6장. 141쪽.