추상팩토리 패턴은 도대체 언제 사용해야할까요?
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
소스코드
파일구성
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도 변경사항에 대해 영향을 받게 됨.
유튜브 강의 링크
'소프트웨어공학 > 디자인패턴 - JAVA' 카테고리의 다른 글
| 프록시 패턴 (Proxy pattern) (0) | 2020.05.31 |
|---|---|
| 전략 패턴 Strategy pattern (0) | 2017.06.10 |
| 어댑터 패턴 Adapter Pattern (0) | 2017.06.10 |
| 상태패턴 State Pattern (0) | 2017.06.10 |
| 팩토리 메소드 Factory method (0) | 2017.06.10 |
