3. 추상 팩토리 패턴 (Abstract factory Pattern)

 

추상 팩토리 패턴 

서로 관련 있는 객체를 만들어주는 인터페이스.

팩토리 패턴과 유사하지만 초점이 Clinet에 맞추어 졌다고 할 수 있다.

목적: 팩토리에서 인스턴스를 만들어 사용하는 Client코드를 인터페이스 기반으로 코딩할 수 있도록 도와준다.

 

복잡해 보이지만, 이전의 팩토리 메서드 패턴에서 Client가 추가된 것 뿐이다.

 

 

아래와 같은 Car Factory가 있다고 하자.

아래의 createCar 메소드 안에서 WhiteHandle과 WhiteWheel을 직접 new 해서 넣어주고 있다.

하지만 만략 WhiteHandle이 규격이 바뀌어서 이제 WhiteAdvancedHandle을 넣어야 한다면?

이렇게 규격이 바뀔 때 마다 계속해서 코드를 수정해줘야 한다.

즉 현재 구체적인 클래스에 의존하고 있어서 발생하는 문제이다.

 

이제 추상 팩토리 메서드 패턴을 적용하면 어떻게 바뀌는지 살펴보자.

 

 

 

1. 추상 팩토리 만들기

현재 Client(CarFactory)의 코드 부분의 수정은 Wheel, Handle같은 Parts들을 만드는 곳에서 발생한다. 하여 위와 같이 각 Parts들(Handle, Wheel)을 interface로 만든 뒤, 각 Part들을 만들어 반환하는 interface를 정의한다.

 

2. 실제 Factory만들기

WhiteHandle과, WhiteWheel을 만드는 Factory를 위에서 만든 추상 팩토리를 implements하게 하여 팩토리를 구체화한다.

해당 Factory는 WhiteHandle, WhiteWheel을 위한 팩토리이다.

 

3. Client코드

이제 Client코드에서는 필드로 인터페이스타입의 factory를 선언한다. 그리고 생성자에서 이를 구체화한다.

20~21라인을 보면 Handle과 Wheel을 set하는 부분이 구체적인 클래스에서 인터페이스에 의존함으로써 결합력이 느슨해진 것을 알 수 있다.

 

이제 변경에 매우 닫혀있는 코드가 되었다. 만약 WhiteCar가 업그레이드 되어서 이제 WhiteHandle, WhiteWheel이 아니라, 

WhiteProHandle, WhiteProWheel을 사용한다면?? 

아래와 같이 추상팩토리를 구현하여 WhiteProHandle, WhiteProWheel을 만드는 Parts factory를 만들면 된다.

 

 

Client코드는 수정할 것이 없다. 생성자에 WhiteCarPartsProFactory 인스턴스만 넣어주면, ProParts들을 set할 수 있다.

 

 

 

 

 

Factory Methods Pattern VS Abstract Factory Pattern

팩토리 메소드 패턴과 추상 팩토리패턴을 비교해보자.

 

팩토리 메소드 패턴 : 인스턴스를 만드는 과정에 집중이 되어 있다.

추상 팩토리 메소드 패턴 : 클라이언트의 입장에서 클라이언트가 추상화된 인퍼페이스를 통해 객체를 생성할 수 있도록 해준다.

 

공통점: 둘 다 구체적인 객체 생성 과정을 추상화한 인터페이스를 제공한다.

 

팩토리 메서드 패턴은 "팩토리를 구현하는 방법 (inheritance)"에 초점을 두고, 

추상 팩토리 패턴은 "팩토리를 사용하는 방법 (compositoin)"에 초점을 둔다.

 

목적이 꽤나 다른데,

팩토리 메서드 패턴은 구체적인 인스턴스 생성 과정을 하위 또는 구체적인 클래스로 옮기는 것이 목적이고, 

추상 팩토리 패턴은 관련있는 여러 객체를 구체적인 클래스에 의존하지 않고 만들 수 있게 해주는 것이 목적이다.

 

 

스프링에서 제공하는 FactoryBean이 추상 팩토리 메서드 패턴이 적용되어 있다.

 

출처: 인프런 백기선님 '코딩으로 학습하는 GoF 강의'
https://www.inflearn.com/course/%EB%94%94%EC%9E%90%EC%9D%B8-%ED%8C%A8%ED%84%B4