팩토리 메소드 패턴은 인스턴스를 만드는 절차를 추상화하는 패턴
객체를 생성하기 위한 인터페이스를 정의하는데, 어떤 클래스의 인스턴스를 만들지는 서브클래스에서 결정하게 만듦.
즉, 팩토리 메소드 패턴을 이용하면 클래스의 인스턴스를 만드는 일을 서브클래스에게 맡기는 것.
single method가 여러 종류의 객체를 생성하는 것.
팩토리 패턴 예시
getInstance() 메소드를 통해 인스턴스 반환하는데, User 클래스 내부에서는 Product 객체를 직접 생성하지 않음.
팩토리 클래스에 인스턴스 요청, 생성된 인스턴스를 반환받는 것으로 사용.
Product 생성자가 변경될 때는 Factory의 getInstance() 메소드 내부의 Product 생성자만 변경시켜주면 됨
(https://velog.io/@ellyheetov/Factory-Pattern)
팩토리 패턴의 장단점
장점
- 느슨한 결합구조를 통한 확장에 열려있고 변경에 닫혀있는 객체 지향 원칙을 만족
- 기존 코드 수정하지 않고 새로운 인스턴스를 여러방법으로 생성할 수 있음 (추상화, 다형성) - 단일 책임 원칙을 따른다. 프로그램의 코드에서 생성자 코드를 분리함으로써 코드를 더욱 간결하게 만들 수 있다
- 개방 폐쇄 원칙을 따른다. 기존 client의 코드를 파괴하지 않고 새로운 타입을 추가 할 수 있다
단점
- 제품이 추가됨에 따라 제품을 생성하는 팩토리도 추가 -> 관리할 클래스가 선형적으로 증가 및 코드 복잡도 증가
추상 팩토리 패턴
인터페이스를 이용하여 서로 연관되거나 의존하는 객체를 구상 클래스를 지정하지 않고도 생성
추상 팩토리 패턴과의 차이점
팩토리 메소드 패턴은 각각 다른 객체들이 필요할 때 사용, 추상 팩토리 패턴은 서로 연관있는 객체들의 조합이 필요할 때 사용
팩토리 메소드 패턴
NYPizzaSotre의 CreatePizza() 함수가 NYCheesePizza, NYClamPizza 등 모두 생산
즉, 하나의 메소드가 여러 종류의 Pizza 생성
추상 팩토리 패턴
ChicagoIngredientFactory는 팩토리 메소드 패턴의 NYPizzaStore와 유사: 상위 interface 구현
차이점을 살펴보면, createDough() 메소드가 생성하는 객체는 ThinCrustDough 한 가지 뿐이다
createSauce(), createCheese() 도 마찬가지
즉, 여러 종류를 생산하는 메소드가 아닌, factory object별 한 종류의 객체를 생성한 것 -> 한 종류의 제품군을 생성할 때 유리하게 사용
references
- https://biggwang.github.io/2019/06/28/Design%20Patterns/%5BDesign%20Patterns%5D%20%ED%8C%A9%ED%86%A0%EB%A6%AC%20%ED%8C%A8%ED%84%B4,%20%EB%8F%84%EB%8C%80%EC%B2%B4%20%EC%99%9C%20%EC%93%B0%EB%8A%94%EA%B1%B0%EC%95%BC-%EA%B8%B0%EB%B3%B8%20%EC%9D%B4%EB%A1%A0%ED%8E%B8/
- https://beomseok95.tistory.com/246
- https://whereami80.tistory.com/211
- https://velog.io/@ellyheetov/Factory-Pattern
