팩토리 패턴 또는 팩토리 메소드 패턴은 객체를 생성하기 위한 인터페이스 또는 추상 클래스를 정의하지만 하위 클래스가 인스턴스화할 클래스를 결정하도록 합니다.
즉, 하위 클래스는 클래스의 인스턴스를 생성할 책임이 있습니다.
팩토리 메서드 패턴은 가상 생성자라고도 합니다.
팩토리 디자인 패턴의 장점
- 팩토리 메서드 패턴을 사용하면 하위 클래스에서 생성할 객체 유형을 선택할 수 있습니다.
- 응용 프로그램별 클래스를 코드에 바인딩할 필요를 제거하여 느슨한 결합을 촉진합니다 .
즉, 코드는 결과 인터페이스 또는 추상 클래스와만 상호 작용하므로 해당 인터페이스를 구현하거나 해당 추상 클래스를 확장하는 모든 클래스와 함께 작동합니다.
팩토리 디자인 패턴의 활용
- 클래스가 만드는 데 필요한 하위 클래스를 모르는 경우
-
클래스가 하위 클래스가 생성할 객체를 지정하기를 원할 때.
-
상위 클래스가 하위 클래스에 대한 객체 생성을 선택하는 경우.
팩토리 메소드 패턴용 UML
Plan 추상 클래스와 Plan 추상 클래스를 확장하는 구체적인 클래스를 만들 것입니다.팩토리 클래스 GetPlanFactory는 다음 단계로 정의됩니다.
- GenerateBill 클래스는 GetPlanFactory를 사용하여 Plan 개체를 가져옵니다. 정보(DOMESTICPLAN / COMMERCIALPLAN / INSTITUTIONALPLAN)를 GetPalnFactory에 전달하여 필요한 개체 유형을 가져옵니다.
코드에서 작업해야 하는 개체의 정확한 유형과 종속성을 사전에 알지 못하는 경우 팩토리 메서드를 사용합니다.
Factory Method는 제품 구성 코드와 제품을 실제로 사용하는 코드를 분리합니다. 따라서 제품 구성 코드를 나머지 코드와 독립적으로 확장하는 것이 더 쉽습니다.
예를 들어 앱에 새 제품 유형을 추가하려면 새 생성자 하위 클래스를 만들고 그 안에 있는 팩토리 메서드를 재정의하기만 하면 됩니다.
라이브러리 또는 프레임워크 사용자에게 내부 구성 요소를 확장하는 방법을 제공하려는 경우 Factory Method를 사용합니다.
상속은 아마도 라이브러리나 프레임워크의 기본 동작을 확장하는 가장 쉬운 방법일 것입니다. 그러나 프레임워크는 표준 구성 요소 대신 하위 클래스를 사용해야 한다는 것을 어떻게 인식합니까?
해결책은 프레임워크 전체에서 구성 요소를 구성하는 코드를 단일 팩터리 메서드로 줄이고 구성 요소 자체를 확장하는 것 외에도 누구나 이 메서드를 재정의할 수 있도록 하는 것입니다.
어떻게 작동하는지 봅시다. 오픈 소스 UI 프레임워크를 사용하여 앱을 작성한다고 상상해 보십시오. 앱에는 둥근 버튼이 있어야 하지만 프레임워크는 정사각형 버튼만 제공합니다.Button영광스러운 하위 클래스로 표준 클래스를 확장합니다RoundButton.UIFramework그러나 이제 기본 클래스 대신 새 버튼 하위 클래스를 사용하도록 기본 클래스에 알려야 합니다 .
UIWithRoundButtons이를 달성하려면 기본 프레임워크 클래스에서 하위 클래스를 만들고 해당createButton메서드를 재정의합니다. 이 메서드는 Button기본 클래스의 개체를 반환하는 동안 하위 클래스가RoundButton개체를 반환하도록 합니다. 이제 UIWithRoundButtons대신 클래스를 사용하십시오UIFramework.
매번 재구축하는 대신 기존 개체를 재사용하여 시스템 리소스를 절약하려는 경우 Factory Method를 사용합니다.
데이터베이스 연결, 파일 시스템 및 네트워크 리소스와 같은 대규모의 리소스 집약적 개체를 처리할 때 이러한 요구를 자주 경험합니다.
기존 객체를 재사용하려면 무엇을 해야 하는지 생각해 봅시다.
1. 먼저, 생성된 모든 객체를 추적하기 위해 스토리지를 생성해야 합니다.
2. 누군가 개체를 요청하면 프로그램은 해당 풀 내에서 사용 가능한 개체를 찾아야 합니다.
3. 그런 다음 클라이언트 코드로 반환합니다.
4. 사용 가능한 개체가 없으면 프로그램은 새 개체를 만들고 풀에 추가해야 합니다.
이 코드를 배치할 수 있는 가장 분명하고 편리한 위치는 재사용하려는 개체가 있는 클래스의 생성자일 것입니다.
그러나 생성자는 항상 정의에 따라 새 객체를 반환해야 합니다 . 기존 인스턴스를 반환할 수 없습니다.
따라서 기존 개체를 재사용할 뿐만 아니라 새 개체를 만들 수 있는 일반적인 메서드가 필요합니다. 그것은 공장 방법과 매우 흡사합니다.
팩토리 패턴(Factory Pattern)은 소프트웨어 개발에서 객체 생성을 추상화하는 디자인 패턴입니다.
이 패턴은 객체 생성을 호출하는 코드로부터 객체의 구체적인 클래스를 분리하여 유연성과 확장성을 제공합니다.
팩토리 패턴은 생성 패턴 중 하나로, 객체 생성에 관련된 복잡성을 감소시키고 코드를 느슨하게 결합시키는데 사용됩니다.
팩토리 패턴
1.추상 팩토리(Abstract Factory): 객체를 생성하기 위한 인터페이스를 정의합니다. 이 인터페이스는 생성된 객체의 타입을 알지 못하더라도 객체를 생성할 수 있도록 합니다.
2.구체적인 팩토리(Concrete Factory): 추상 팩토리 인터페이스를 구현하며, 실제로 객체를 생성하는 역할을 합니다. 구체적인 팩토리는 클라이언트의 요청에 따라 적절한 객체를 생성하여 반환합니다.
3.추상 제품(Abstract Product): 생성될 객체의 공통 인터페이스를 정의합니다. 이 인터페이스는 생성되는 객체들이 공통으로 가져야 하는 메서드를 선언합니다.
4.구체적인 제품(Concrete Product): 추상 제품 인터페이스를 구현하는 실제 객체입니다. 구체적인 팩토리에 의해 생성되고, 추상 팩토리를 통해 사용됩니다.
팩토리 패턴의 작동 과정
-
클라이언트(Client)가 객체를 생성하기 위해 추상 팩토리를 호출합니다.
-
추상 팩토리는 적절한 구체적인 팩토리를 선택하여 반환합니다.
-
구체적인 팩토리는 요청된 객체를 생성하여 반환합니다. 이때 생성되는 객체는 추상 제품을 구현한 구체적인 제품입니다.
-
클라이언트는 반환된 객체를 사용하여 필요한 작업을 수행합니다. 클라이언트는 생성된 객체가 실제로 어떤 클래스의 인스턴스인지 알 필요가 없습니다.
팩토리 패턴은 다양한 상황에서 유용하게 사용될 수 있습니다.
예를 들어, 객체 생성이 복잡하거나 다른 클래스와 강하게 결합되어 있는 경우 팩토리 패턴을 사용하여 객체 생성 코드를 캡슐화하고, 이를 통해 유지보수성과 확장성을 향상시킬 수 있습니다.
또한, 팩토리 패턴은 객체 생성을 중앙 집중화하여 일관성 있는 객체 생성을 보장할 수 있습니다.
팩토리 패턴의 장점
-
객체 생성 코드와 사용 코드를 분리하여 의존성을 낮춥니다.
-
클라이언트는 객체의 구체적인 클래스에 대한 정보를 알 필요가 없습니다.
-
객체 생성을 중앙 집중화하여 일관성 있는 객체 생성을 보장합니다.
-
객체 생성 코드를 캡슐화하여 유지보수성과 확장성을 향상시킵니다.
팩토리 패턴의 단점
-
객체 생성을 위해 추가적인 팩토리 클래스를 구현해야 하므로 초기 구조 설계 시에는 약간의 복잡성을 초래할 수 있습니다.
-
객체 생성에 대한 추상화 수준이 추가되므로 일부 성능 손실이 발생할 수 있습니다.
팩토리 패턴은 객체 지향 설계 원칙 중 하나인 "의존성 역전 원칙(Dependency Inversion Principle)"을 따르는 방법 중 하나입니다.
이 원칙은 의존 관계를 형성하는 객체 사이에서 구체적인 구현 대신에 추상화된 인터페이스에 의존해야 한다는 것을 강조합니다.
팩토리 패턴은 이 원칙을 따르며, 의존성을 객체 생성에 대한 추상화된 팩토리로 전환하여 유연하고 확장 가능한 코드를 작성할 수 있게 합니다.
