Factory 패턴

출처: https://refactoring.guru/ko/design-patterns

디자인 패턴들

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

 문제

당신이 물류 관리 앱을 개발하고 있다고 가정합시다. 앱의 첫 번째 버전은 트럭 운송만 처리할 수 있어서 대부분의 코드가 Truck​(트럭) 클래스에 있습니다.

또 얼마 후 당신의 앱이 유명해졌으며, 매일 해상 물류 회사들로부터 해상 물류 기능을 앱에 추가해 달라는 요청을 수십 개씩 받기 시작했다고 가정해 봅시다.

나머지 코드가 이미 기존 클래스들에 결합되어 있다면 프로그램에 새 클래스를 추가하는 일은 그리 간단하지 않습니다.

좋은 소식이죠? 그러나 현재 대부분의 코드는 Truck 클래스에 결합되어 있습니다. 앱에 Ship​(선박) 클래스를 추가하려면 전체 코드 베이스를 변경해야 합니다. 또한 차후 앱에 다른 유형의 교통수단을 추가하려면 아마도 다시 전체 코드 베이스를 변경해야 할 것입니다.

그러면 결과적으로 많은 조건문이 운송 수단 객체들의 클래스에 따라 앱의 행동을 바꾸는 매우 복잡한 코드가 작성될 것입니다.

 해결책

팩토리 메서드 패턴은 (new 연산자를 사용한) 객체 생성 직접 호출들을 특별한 팩토리 메서드에 대한 호출들로 대체하라고 제안합니다. 걱정하지 마세요: 객체들은 여전히 new 연산자를 통해 생성되지만 팩토리 메서드 내에서 호출되고 있습니다. 참고로 팩토리 메서드에서 반환된 객체는 종종 제품이라고도 불립니다.

자식 클래스들은 팩토리 메서드가 반환하는 객체들의 클래스를 변경할 수 있습니다.

얼핏 이러한 변경은 무의미해 보일 수도 있는데, 그 이유는 생성자 호출을 프로그램의 한 부분에서 다른 부분으로 옮겼을 뿐이기 때문입니다. 그러나 위와 같은 변경 덕분에 이제 자식 클래스에서 팩토리 메서드를 오버라이딩하고 그 메서드에 의해 생성되는 제품들의 클래스를 변경할 수 있게 되었습니다.

하지만 약간의 제한이 있긴 합니다. 자식 클래스들은 다른 유형의 제품들을 해당 제품들이 공통 기초 클래스 또는 공통 인터페이스가 있는 경우에만 반환할 수 있습니다. 또 이전에 언급한 모든 제품들에 공통인 Transport 인터페이스로 Logistics 기초 클래스의 create­Transport 팩토리 메서드의 반환 유형을 선언해야 합니다.

모든 제품들은 같은 인터페이스를 따라야 합니다.

예를 들어 Truck 과 Ship 클래스들은 모두 Transport 인터페이스를 구현해야 하며, 이 인터페이스는 deliver​(배달)​라는 메서드를 선언합니다. 그러나 각 클래스는 이 메서드를 다르게 구현합니다. 트럭은 육로로 화물을 배달하고 선박은 해상으로 화물을 배달합니다. Road­Logistics​(도로 물류) 클래스에 포함된 팩토리 메서드는 Truck 객체들을 반환하는 반면 Sea­Logistics​(해운 물류) 클래스에 포함된 팩토리 메서드는 선박 객체들을 반환합니다.

모든 제품 클래스들이 공통 인터페이스를 구현하는 한, 제품 클래스들의 객체들을 손상하지 않고 클라이언트 코드를 통과시킬 수 있습니다.

팩토리 메서드를 사용하는 코드를 종종 클라이언트 코드라고 부르며, 클라이언트 코드는 다양한 자식 클래스들에서 실제로 반환되는 여러 제품 간의 차이에 대해 알지 못합니다. 클라이언트 코드는 모든 제품을 추상 Transport​(운송체계)​로 간주합니다. 클라이언트는 모든 Transport 객체들이 deliver​(배달) 메서드를 가져야 한다는 사실을 잘 알고 있지만, 이 메서드가 정확히 어떻게 작동하는지는 클라이언트에게 중요하지 않습니다.