[Creational Pattern] Abstract Factory(추상 팩토리)

https://m.hanbit.co.kr/channel/category/category_view.html?cms_code=CMS8616098823

 

Design Pattern의 첫 포스팅이다. 먼저 디자인패턴에 대한 간략한 설명을 하자면, 우리가 인프라 시스템을 구축하는 것을 Architect Pattern이라고 한다. 클라이언트-서버가 예시이다.

 

Design Pattern은 서버면 서버, 클라이언트면 클라이언트 별로 더 세세하게 설계를 한다는 것이다. Architect Pattern은 건물로 비교하자면 윤곽을 잡는 것이라면 Design Pattern은 건물의 방의 인테리어를 설계하는 것이라고 볼 수 있다는 것이다.

 

즉, Design Pattern은 모듈 간의 관계 및 인터페이스(Interface)를 설계할 때 참조할 수 있는 전형적인 해결방식 또는 예제를 의미한다.

# Interface란?

 

 사전적의미의 Interface는 "경계면"을 의미한다. CS에서 Interface도 같은 맥락으로 해석될수 있다. 인터페이스를 설계한다는 것은 "추상화 시키기"다.

 

자동차를 생각해보자. 우리가 오늘 엑셀을 밞았을 때, 엔지니어가 아닌 일반적인 사용자들이 엔진이 어떻게 동작하는지 알까? 아니면 알아야할까?

 

그렇지않다. 내 차는 앞으로 가기만 하면된다. 이게 Interface이다.
엑셀이 사용자 입장에서 인터페이스라는 것이다.  

# GoF(Gang of Four)

디자인 패턴은 Erich Gamma, Richard Helm, Ralph Johnson, John Vissides 인물들이 구체화했다. 소프트웨어 공학에서 표준화된 디자인 패턴이라고 볼 수 있다. GoF Design Pattern은 두 가지로 분류할 수 있다.

# 목적에 따른 분류

목적에 따른 분류로는 3가지로 분류할 수있다. [생성, 구조, 행동]으로 분류하여 각 패턴들이 어떤 일을 하기 위한 것인지 분류를 한다.

 

- Creational Pattern: 생성 과정에 관여

- Structural Pattern: 객체의 합성에 관여

- Behavior Pattern: 객체가 상호작용하는 방법이나 관심사를 분리하는 방법에 관여  

# 범위에 따른 분류

[클래스, 객체]에 따른 분류할 수도 있다. 디자인 패턴들을 객체에 사용하는지, 클래스에 사용하는지 분류한다. 클래스 패턴은 클래스와 서브 클래스의 상속에 관련되어 있어 static하며, 객체 패턴은 객체를 다뤄 Dynamic 하다.

 

오늘 포스팅에서 알아볼 내용은 Creational Pattern의 Abstract Factory(추상 팩토리)에 대해서 알아보겠다.

---

# Abstract Factory(추상 팩토리) Pattern

Creational Pattern과 객체 패턴으로 관련 있는 객체의 집합을 생성하기 위한 Interface를 제공하는 Design Pattern이다. 이 패턴은 객체 생성을 담당하는 코드를 Client 코드로 부터 분리하여 유연성과 확장성을 올린다.

 

사실 말을 읽어보면 제대로 이해가 가지 않는다. [ 관련 있는 객체의 집합 ]은 무엇을 의미하는 것일까? 

 

민속게임중 하나인 "스타크래프트 테란 종족"으로 비유를 해보겠다.

테란 종족에게는  [유닛을 생산하는 시설 (Abstract Factory)]이 있다.

 

 

각각 유닛을 생산하는 시설인 배럭, 팩토리, 스타포트[ Concrete Factories]가 있다. 하지만 이 유닛을 생산하는 시설은 각각 다른 특성의 유닛들을 생산해낸다.

• 배럭(Concrete Factory A) : 마린, 메딕, 파뱃, 고스트(Products A)
• 팩토리 (Concrete Factory B) : 시즈탱크, 골리앗, 벌쳐 (Products B)
• 스타포트 (Concrete Factory C) : 레이스, 발키리, 배슬, 배틀크루즈 등등 (Products C)

스타크래프트에 비교를 했더니 이해를 할 수 있었다. [관련 있는 객체의 집합을 생성하기 위한 Interface]라는 것이다.

 

Abstract Factory Pattern가 아니라고 한다면, 배럭따로, 팩토리 따로, 스타포트 따로 클래스를 만들어야 한다는 것이다. 하지만 Abstract Factory Pattern으로 개발하다면 하나의 [유닛을 생산하는 시설]로 클래스를 한번 더 묶을 수 있다.

 

# 패턴을 사용할때

추상화 패턴의 궁극적인 목표는 "군"을 한번 더 묶어 구체적인 클래스에 의존하지 않는 것이다. 그럴때 사용하면 된다.

 

"난 배럭, 팩토리, 스타포트 중에 배럭에서 마린만 뽑을거야"가 아닌

"난 유닛을 생산하는 시설에서 배럭에서 마린만 뽑을거야" 가 가능해지는 것이다.

 

새로운 제품군을 추가 할때도 마찬가지이다. 클라이언트 코드는 변경하지 않아도 된다. 새롭게 Concrete Factory를 구성만한다면 쉽게 시스템을 변경할 수 있다.

# 장점

• 코드의 결합도를 낮출 수 있음
• 제품군 쉽게 대체 가능
• OPP - SRP 준수
• OPP - OCP 준수

# 단점

• Concrete Factory를 모두 구성해줘야한다.
• 상위인 Abstract Factory를 변경하게 되면 하위인 Concrete Factory를 모두 변경해야한다.

 

# 참고문헌

https://4z7l.github.io/2020/12/25/design_pattern_GoF.html

[Design Pattern] GoF(Gang of Four) 디자인 패턴 - HERSTORY

https://namu.wiki/w/%EB%94%94%EC%9E%90%EC%9D%B8%20%ED%8C%A8%ED%84%B4#s-3.1

디자인 패턴

https://inpa.tistory.com/entry/GOF-%F0%9F%92%A0-%EC%B6%94%EC%83%81-%ED%8C%A9%ED%86%A0%EB%A6%ACAbstract-Factory-%ED%8C%A8%ED%84%B4-%EC%A0%9C%EB%8C%80%EB%A1%9C-%EB%B0%B0%EC%9B%8C%EB%B3%B4%EC%9E%90

💠 추상 팩토리(Abstract Factory) 패턴 - 완벽 마스터하기