프로그래머스 데브코스 10일차 - 팩토리 패턴

매일 매일 적었어야 했는데..! 발표에 과제에 너무나도 치였다..! 몰아적는건 좋지 않지만 그래도 했던 기록은 남기고자 한다.

다음 날 있을 디자인 패턴 스터디의 발표 자료를 준비했다! 해당 발표 자료를 올리고자 한다.

내가 생각하는 팩토리 패턴의 구조

기본적으로 간단한 팩토리는 패턴으로 사용하지 않고 관용구로 사용한다고 하는데, 팩토리 메서드 패턴과 추상 팩토리 패턴의 기본적인 틀은 Simple Factory를 따라가는 것 같아서 위와 같이 표현을 했다.

Simple Factory 자체는 프로그래밍에서 자주 쓰이는 관용구이고, 디자인 패턴은 아닙니다. 하지만 같은 개념을 확장한 Factory Method와 Abstract Factory는 패턴입니다.

팩토리 : 주로 객체 생성을 처리하는 클래스를 의미합니다.

팩토리 패턴은 왜 사용하는가

팩토리 패턴을 사용하는 이유는 클라이언트 코드와의 결합도를 낮추기 위해서 사용합니다. 어떤 객체의 생성자가 새로운 기능이 추가되면서 계속해서 변경점이 이루어지면 클라이언트 코드 또한 계속해서 변경이 이루어지게 됩니다.

Pizza pizza = new Pizza("피자이름"); // 이것만 사용하다가.
Pizza pizza = new Pizza("피자이름", "가게"); // 이렇게 추가되면 클라이언트 코드는 변경가능성에 노출

이러한 문제를 해결하기 위해 팩토리에게 객체 생성을 위임하게 되면 클라이언트는 변경 가능성을 낮추게 되어 결합도가 낮아지게 됩니다.

Pizza pizza = factory.createPizza("피자이름"); 
// 여기선 String을 사용했지만 Enum을 사용하는 것이 좋습니다.

위처럼 생성된 방식을 간단한 팩토리라고 정의합니다. 하지만 이는 위에서 얘기했듯이 아직까지 패턴은 아닙니다. 객체간의 결합성을 끊기 위해 간단한 팩토리 방식을 사용하더라도 다음과 같은 클래스 폭발은 막을 수 없습니다.

클래스 폭발

팩토리 패턴의 종류

팩토리 메서드 패턴

팩토리 메서드 패턴 : 부모 클래스에서 객체들을 생성할 수 있는 인터페이스를 제공하고, 자식 클래스들이 생성될 객체들의 유형을 변경할 수 있도록 하는 생성 패턴

팩토리 메서드 패턴 클래스 다이어그램

위의 구조 처럼 Factory 라는 객체를 생성하는 공장 클래스를 만들고, 이를 상속하는 서브 공장 클래스의 메서드에서 여러가지 제품 객체 생성을 각각 책임 지는 것입니다.

직접 구현

여기서 팩토리 메서드 패턴의 의미가 보입니다. 부모 클래스의 생성메서드 내부에 추상 메서드를 넣어 구상 클래스별로 객체가 각각 다르게 생성되는 것입니다.

사실 팩토리 메서드 패턴에는 한 가지 패턴이 추가로 들어가있는데요. 바로 템플릿 메서드 패턴이 섞여있습니다. 팩토리 메서드의 메서드는 사실 템플릿 메서드의 메서드에서 따 온 것입니다.

팩토리 메서드 패턴의 단점

하지만 간단한 팩토리 패턴과 동일하게 계속해서 새로운 Product들이 생성되면 클래스 폭발 문제가 발생 할 수 있습니다.

팩토리 메서드 패턴의 결론

팩토리 메서드 패턴은 Factory 객체에 객체를 생성하기 위한 메서드를 생성해두고 구상 클래스에 따라 템플릿 메서드 패턴을 활용하여 각기 다르게 객체를 생성하는 패턴 이라는 결론을 내릴 수 있습니다.

추상 팩토리 패턴

추상 팩토리 패턴 : 구상 클래스에 의존하지 않고도 서로 연관되거나 의존적인 객체로 이루어진 제품군을 생산하는 인터페이스를 제공합니다. 구상 클래스는 서브 클래스에서 만듭니다.

추상 팩토리 패턴

추상 팩토리 패턴의 클래스 다이어그램을 살펴보면 이전에 팩토리 메서드 패턴과 어떤 차이가 있는지 바로 느낄 수 있습니다.

팩토리 메서드 패턴에서는 하나의 제품군에만 관심이 있던 반면, 추상 팩토리 패턴에서는 각 제품들에 대해서 또 하나의 그룹을 생성하고, 그룹 별로 맞는 제품을 생성할 수 있도록 도와줍니다.

추상 팩토리 패턴 구현

클래스 다이어그램을 코드로 나타내면 위와 같고, 위 처럼 제품 군을 생성하는 팩토리를 하나 더 두어서 생성하는 방식입니다.

추상 팩토리 패턴의 단점

1️⃣ 추상 팩토리 패턴의 단점은 새로운 제품군이 생길 때마다 인터페이스를 추가하고, 또 제품 군을 구현하기 위한 코드를 추가해주어야 합니다. 이러한 문제로 인해 코드가 굉장히 복잡해질 수 있습니다. 이는 팩토리 메서드 패턴과 동일한 단점입니다.

2️⃣ 추상 팩토리의 세부사항이 변경되면 모든 팩토리에 대한 수정이 필요해진다.

추상 팩토리 패턴 결론

기존의 팩토리 패턴에서 더 나아가, 새로운 제품군이 형성되면 해당 제품군에 맞는 제품을 바로 생성 할 수 있게 해주는 패턴입니다. 이는 팩토리 패턴에서 그룹화를 한 번 더 하게 된 방식으로 이해 할 수 있습니다.

팩토리 메서드와 추상 팩토리의 차이

팩토리 메서드와 추상 팩토리는 2지선다가 아닙니다. 각각이 다른 관점에서 사용해야 하는 다른 패턴이고, 이에 따라 둘은 결합도 가능합니다.

팩토리 메서드 패턴은 추상 메서드를 통해서 객체 생성에 있어서 전처리와 후처리를 해줍니다. 즉, 무거운 객체를 생성 할 때 동일한 어떠한 작업들을 각각의 구상 클래스들에 따라 다르게 생성하는 방식입니다. 추상 팩토리는 다양한 타입의 제품 군을 한데 묶어서 생성하는 방식입니다.

	추상 팩토리 패턴	팩토리 메서드 패턴
공통점	객체 생성 과정을 추상화한 인터페이스를 제공객체 생성을 캡슐화함으로써 구체적인 타입을 감추고 느슨한 결합 구조를 표방
차이점	관련 있는 여러 객체를 구체적인 클래스에 의존하지 않고 만들 수 있게 해주는 것이 목적	구체적인 객체 생성과정을 하위 또는 구체적인 클래스로 옮기는 것이 목적
	Factory에서 서로 연관된 여러 종류의 객체 생성을 지원. (제품군 생성 지원)	Factory당 한 종류의 객체 생성 지원
	클래스(Factory) 레벨에서 포커스를 맞춤으로써, 클라이언트의 ConcreteProduct 인스턴스 군의 생성 및 구성에 대한 의존을 감소	메소드 레벨에서 포커스를 맞춤으로써, 클라이언트의 ConcreteProduct 인스턴스의 생성 및 구성에 대한 의존을 감소

이 패턴을 책을 보고 공부했을 때 정말 이해가 안됐었다. 아마 템플릿 메서드 패턴이 뭔지 몰라서 그랬던 것 같기도 하다. 확실히 한 번 디자인 패턴을 다 돌리고 난 뒤에 보게 되면 다르게 느껴지지 않을까 생각이 든다!

그리고 이렇게 열심히 공부를 하면서 준비하게 된 것도 스터디의 영향이 정말 큰 것 같다 스터디원 분들 짱짱!

 

참고 자료

1. 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/
2. https://inpa.tistory.com/entry/GOF-%F0%9F%92%A0-%EC%B6%94%EC%83%81-%ED%8C%A9%ED%86%A0%EB%A6%ACAbstract-Factory-%ED%8C%A8%ED%84%B4-%EC%A0%9C%EB%8C%80%EB%A1%9C-%EB%B0%B0%EC%9B%8C%EB%B3%B4%EC%9E%90
3. https://inpa.tistory.com/entry/GOF-%F0%9F%92%A0-%ED%8C%A9%ED%86%A0%EB%A6%AC-%EB%A9%94%EC%84%9C%EB%93%9CFactory-Method-%ED%8C%A8%ED%84%B4-%EC%A0%9C%EB%8C%80%EB%A1%9C-%EB%B0%B0%EC%9B%8C%EB%B3%B4%EC%9E%90
4. https://refactoring.guru/ko/design-patterns/abstract-factory
5. https://refactoring.guru/ko/design-patterns/factory-method