[디자인 패턴] - Abstract Factory

Abstract Factory(추상 팩토리)

만들어야 할 컴포넌트들을 추상적으로 정의한 후 구체적인 상황이 주어지면 앞에 만들어진 추상적인 컴포넌트들을 해당 상황에 맞게 구체적으로 만드는 패턴이다. 

 

만약 운영체제 여러 개의 버튼, 체크박스, 텍스트에디트 기능을 만들어야 한다고 가정 하자.

추상팩토리를 이용하지 않고 만든다면 운영체제 OS 중 Windows에 한 클래스에 버튼, 체크박스, 텍스트에디트 이 부분을 다 정의해야한다. Linux 를 추가로 만든다고 하면 Linux 클래스에  버튼, 체크박스, 텍스트에디트를 다 정의해서 작성해줘야한다.  물론 이렇게 만들 수있지만 여기서는 Windows, Linux만 얘기를 했지만 더 많은 종류가 추가되야한다면 그리고 예를 들어 버튼을 만들어낸 모든 OS 종류의 클래스에 버튼을 비활성화 한다면? 각 OS 클래스 종류별로 하나씩 코드를 펼쳐 다 비활성화 해줘야한다. 

 

하지만 추상팩토리로 나눈다면 상속을 해준 추상클래스의 버튼기능의 부분만 수정해주면 된다. 

장단점을 정리하자면 다음과 같다. 

 

장점

구체적인 클래스에 의존하지 않는다.(느슨한 결합)

• 클라이언트는 Component 추상클래스만 사용하므로, 구체적인 클래스(Windows, Linux 등)에 의존하지 않는다.
• 새로운 제품군이 추가될 때(예: MacOSFactory) 기존 코드 변경이 최소화된다.

 

객체 그룹을 일관되게 생성 가능하다.

한 팩토리에서 생성된 객체들은 동일한 환경에서 동작하는 것을 보장할 수 있다.

ex) Windows 요소는 Windows 스타일을 따르고, Linux 요소는 Linux  스타일을 따른다.

 

확장성이 뛰어나다.

새로운 팩토리를 추가하여 새로운 제품군을 쉽게 확장 가능하다.

 ex) MacOSFactory를 추가하면 MacOS 환경도 지원 가능하다.

 

코드 유지보수가 용이하다.

팩토리를 통해 객체 생성을 관리하므로, 제품군이 변경되어도 클라이언트 코드 수정이 최소화된다.

 

단점

구현 복잡도 증가한다.

단순한 객체 생성보다 팩토리 인터페이스, 팩토리 클래스, 제품 인터페이스 등 추가적인 코드가 필요하다.

작은 프로젝트에는 오버헤드가 클 수 있다.

 

새로운 제품군 추가 시 코드 수정 필요하다.

제품군(예: MacOSButton, MacOSCheckbox)을 추가하면 해당하는 팩토리도 새로 만들어야 하므로 코드가 늘어난다.

 

단일 책임 원칙 위반 가능성이 생길 수 있다.

한 개의 팩토리가 여러 개의 제품을 생성할 경우, 팩토리가 너무 많은 책임을 가질 수 있다.

 

Abstract Factory 패턴을 언제 사용할까?

여러 제품군을 일관되게 생성해야 할 때

→ UI 라이브러리(Windows, MacOS, Linux)에 맞는 버튼, 체크박스를 다르게 구현해야 할 때.

 

객체 생성을 캡슐화하고 클라이언트 코드에서 독립시키고 싶을 때

→ 예: 데이터베이스 연결(MySQLConnection, PostgreSQLConnection)을 팩토리로 감싸고 싶을 때.

 

코드를 확장 가능하게 만들고 싶을 때

→ 새로운 제품군이 추가될 가능성이 높은 경우.

 

정리하자면

Abstract Factory 패턴은 관련된 객체를 그룹으로 생성하는 경우 유용한 디자인 패턴이다.
코드의 유연성과 유지보수성을 높일 수 있지만, 구현이 복잡해질 수 있는 단점이 있다.
특히 대규모 프로젝트에서 다양한 환경을 지원해야 할 때 유용하게 활용할 수 있다.