추상 팩토리 패턴 (Abstract factory pattern)

추상팩토리 패턴은 도대체 언제 사용해야할까요?

Simple factory pattern과 차이점은 무엇일까요?

 

사실 필자가 생각하기론 Simple factory pattern과 추상팩토리패턴 (Abstarct Factory pattern)은 거의 흡사하다고 봅니다.

 

다만, 군(플랫폼, 환경, 개체군)으로 관리해야하는 상황이 생기거나 군 밑의 자식클래스(Concrete class)의 잦은 수정이 생길것으로 판단될 때, 추상 팩토리 패턴을 적용해야 미래에 변경용이성을 가져가실 수 있습니다.

 

다시한번 말씀드리지만, 군으로 관리해야하느냐 아니냐에 따라 추상팩토리를 사용하느냐 Simple facotry Pattern을 사용하느냐로 결정하시면 됩니다.

 

 

추상팩토리 패턴이란?

Product class의 생성을 책임지는 생성에 관한 패턴으로써, 군 별로 Product class 를 책임지고 생성하는 Desgin Pattern

 

 

 

예제상황

View개발자들이 있는데 이 개발자들은 자기가 담당하는 View들이 따로있다. (Button, EditText, CloseButton 등등)

그런데 Window와 Linux 에 따라 각각의 View 군들의 Product class들의 생성을 따로 해야하는 상황이다.

 

 

 

Class Diagram

 

Abstract factory class diagram

 

소스코드

파일구성

ButtonView.java
EditTextView.java
FactoryCreator.java
LinuxButtonView.java
LinuxEditTextView.java
LinuxViewFactory.java
Main.java
ViewFactory.java
WindowButtonView.java
WindowEditTextView.java
WindowViewFactory.java

소스코드 Github 

https://github.com/control-man/design_pattern_sample/tree/master/abstarct_factory

 

간략한 소스코드 소개

public class FactoryCreator {
	
	static ViewFactory createViewFactory(String OS) {
		if (OS.equals("window")) {
			return new WindowViewFactory();
		} else if (OS.equals("linux")){
			return new LinuxViewFactory();
		} else {
			return null;
		}
	}
}

public class WindowViewFactory implements ViewFactory {

	@Override
	public ButtonView createButtonView() {
		return new WindowButtonView();
	}

	@Override
	public EditTextView createEditTextView() {
		return new WindowEditTextView();
	}

}

public class LinuxViewFactory implements ViewFactory {

	@Override
	public ButtonView createButtonView() {
		return new LinuxButtonView();
	}

	@Override
	public EditTextView createEditTextView() {
		return new LinuxEditTextView();
	}

}


public class Main {

	public static void main(String[] args) {

		ViewFactory viewFactory = FactoryCreator.createViewFactory("window");
		ButtonView buttonView = viewFactory.createButtonView();
		EditTextView editTextView = viewFactory.createEditTextView();
		
		buttonView.doButtonSomething();
		editTextView.doEditTextSomething();
		
		viewFactory = FactoryCreator.createViewFactory("linux");
		buttonView = viewFactory.createButtonView();
		editTextView = viewFactory.createEditTextView();

		buttonView.doButtonSomething();
		editTextView.doEditTextSomething();
	}

}

 

실행결과

 

장점

- Product 의 하위 클래스인 Concrete Product 클래스의 수정이나 확장이 발생해도 Client Side에서는

영향을 받지 않는다.

 

- 군별로 Product를 생성하는 Factory 클래스를 완전 분리함으로써, 코드 가독성이 올라간다.

 

 

 

단점

Product의 종류가 증가되면 수정되는(영향을 받는) 클래스의 수가 많아진다.

(그러므로 개체의 종류는 최대한 미리 정해놓고 진행하는것이 좋음)

 

만약 Product 가 늘어나면 아래의 Class diagram처럼 변하게 됨 

-> ViewFactory의 인터페이스 수정으로 인해 Concrete View Factory들의 수정사항도 생기고

Client도 변경사항에 대해 영향을 받게 됨.

 

Product가 늘어나게되면 Factory 클래스들의 수정이 발생한다.

 

 

유튜브 강의 링크

 

https://www.youtube.com/watch?v=wu2SIkJpaI0