정리
- 모든 factory pattern에서는 app의 구상 클래스에 대한 dependency를 줄여줘서 loose-coupling을 도와준다.
- 또한 Object 생성을 encapsulation 한다.
- 주로, Super-class와 다수의 sub-class가 있을 때 input을 기준으로 하나의 sub-class를 반환할 경우 사용한다.
- 구상 class가 아닌 추상 class/interface에 맞춰서 코딩할 수 있게 해주는 강력한 기법이다.
Simple Factory
- 디자인 패턴이라 할 수 없고, 자주 쓰이는 관용구라 할 수 있다. Client와 구상 class를 분리시키기 위한 간단한 기법으로 활용한다.
Factory Method Pattern
- Object를 생성하기 위한 Interface를 정의하는데, Object를 생성하는 부분을 Sub-Class에 위임하는 pattern이다.
- 즉 ‘new’키워드를 호출하는 부분을 Sub-Class에 위임하는 것이다.
- 그 결과, class간의 결합도(class의 변경이 있을 경우, 다른 class에 영향을 주는 정도)가 떨어진다.
- SimpleFactory와의 차이점은 Factory Method Pattern은 어떤 구현을 사용할지를 sub-class에서 결정하는 framework를 만들 수 있다는 것이다.
- SimpleFactory에서도 Object생성을 Encapsulation하는 방법을 사용하긴 하지만 생성하는 제품을 마음대로 변경할 수 없기 때문에 Factory Method Pattern처럼 강력한 flexibility를 제공하지는 못한다.
Abstract Factory Pattern
- Interface를 이용하여, 연관성이 있는 많은 sub-class를 특정 그룹으로 묶어 일괄적으로 수정할 수 있도록 하는 pattern이며, 제품을 추가하려면 Interface를 수정하면 된다.
- 예를 들어 특정 library를 배포하는데 국가마다 기능이 상이하다면 abstract factory pattern을 이용해서 일괄적으로 기능을 변경하여 대처할 수 있다.
Dependency Inversion Principle
- 추상화된 것에 의존하도록 하고, 구상 클래스에 의존하지 않도록 해야 한다.
- 어떤 변수에도 구상 클래스에 대한 reference를 지정하지 않는다(new 연산자를 사용하는 것이 reference를 사용하게 되는 것)
- 구상 클래스에서 유도된 클래스를 만들지 않는다. (구상클래스에서 유도된 클래스를 만들면 특정 구상 클래스에 의존하게 된다. 추상화된 것을 사용해야 한다.)
- 클래스에 이미 구현된 메소드를 override 하지 않는다. (이미 구현된 메소드를 override 한다는 것은 클래스가 제대로 abstract 되지 않았다고 할 수 있다. 클래스에 method를 정의할 때에는 모든 sub-class에서 공유할 수 있는 것으로 정의해야 한다.
UML
Frontend