Antigravity Agent
80 lines
6.2 KiB
Markdown
80 lines
6.2 KiB
Markdown
---
|
|
category: Unified
|
|
tags: [auto-consolidated, technical-documentation]
|
|
title: [[Factory Pattern]]
|
|
last_updated: 2026-05-02
|
|
---
|
|
|
|
# [[Factory Pattern]]
|
|
|
|
## 📌 Brief Summary
|
|
Factory Pattern(또는 Factory Method)은 시스템 전체의 구조를 다루는 소프트웨어 아키텍처 패턴과 달리, 컴포넌트 내의 특정한 설계 문제를 해결하기 위해 사용되는 '디자인 패턴(Design Pattern)'의 한 종류입니다 [1, 2]. 제공된 소스에서는 디자인 패턴과 아키텍처 패턴을 비교하는 과정에서 단순 예시로만 한정적으로 언급되어 있어 **소스에 관련 정보가 부족합니다.**
|
|
|
|
---
|
|
|
|
> "객체 생성을 전담하는 대리인." 어떤 구체적인 클래스의 인스턴스를 만들지 결정하는 로직을 별도의 객체나 메서드로 분리하여, 클라이언트 코드가 생성 방식의 변화로부터 자유로워지게 하는 패턴이다.
|
|
|
|
## 📖 Core Content
|
|
**소스에 관련 정보가 부족합니다.**
|
|
|
|
다만, 제공된 문서에서 추출할 수 있는 최소한의 맥락적 정보는 다음과 같습니다:
|
|
* **패턴의 수준 및 범위(Level & Scope):** Factory Pattern은 소프트웨어 아키텍처 패턴과 명확히 구분되는 개념입니다. 아키텍처 패턴이 시스템 전체의 거시적인 구조(Macro-level)와 컴포넌트 간의 상호작용을 정의하는 반면, Factory Pattern을 포함한 디자인 패턴은 단일 컴포넌트나 클래스 내부의 미시적인 수준(Micro-level)에서 발생하는 설계 문제를 다룹니다 [1, 2].
|
|
* **적용 단계(Time of Application):** 시스템 레이아웃을 결정하는 초기 설계(Design) 단계가 아니라, 실제 소프트웨어 개발의 코딩(Coding) 또는 빌드(Building) 단계에서 적용됩니다 [1].
|
|
* **해결 목적(Purpose):** 객체 생성, 클래스 간의 상호작용 및 동작과 같은 반복적인 설계 문제를 해결하여 코드의 재사용성을 높이는 표준화된 솔루션 역할을 합니다 [1, 2].
|
|
|
|
---
|
|
|
|
- **Simple Factory**: 입력값에 따라 다른 자식 객체를 생성하여 리턴함.
|
|
- **Factory Method**: 상속을 통해 어떤 객체를 생성할지 서브클래스가 결정하게 함.
|
|
- **Abstract Factory**: 연관된 객체들의 '군(Family)'을 생성하기 위한 인터페이스를 제공함 (예: 다크 테마용 버튼과 입력창 세트).
|
|
- **Core Benefit**: **Decoupling**. `new` 키워드를 한곳에서 관리하므로, 나중에 구현체가 바뀌어도 사용하는 쪽 코드는 전혀 수정할 필요가 없다.
|
|
|
|
## ⚖️ Trade-offs & Caveats
|
|
**소스에 관련 정보가 부족합니다.** (제공된 소스에는 Factory Pattern의 부작용, 제약 사항, 혹은 최적화 방식에 대한 구체적인 내용이 포함되어 있지 않습니다.)
|
|
|
|
---
|
|
|
|
- 팩토리 패턴은 코드의 유연성을 높이지만, 단순한 객체 생성에도 팩토리를 도입하면 클래스 수가 많아지고 구조가 복잡해지는 '클래스 폭발'을 유발할 수 있다. 객체 생성 로직이 복잡하거나 타입에 따라 분기가 빈번할 때만 선택적으로 사용하는 것이 좋다.
|
|
|
|
## 🔗 Knowledge Connections
|
|
### Related Concepts
|
|
|
|
#### [소프트웨어 설계 분류 (Software Design Classification)]
|
|
- [[Design Pattern]]
|
|
- 연결 이유: Factory Pattern은 명시적으로 디자인 패턴의 한 예시로 분류되며, 아키텍처 패턴의 대조군으로 소개됩니다 [1, 2].
|
|
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 거시적인 아키텍처 구조 내부에서 세부적인 컴포넌트 구현 시 직면하는 문제를 어떻게 해결하는지(재사용성, 가독성 향상 등) 그 목적을 이해할 수 있습니다 [2, 3].
|
|
|
|
- [[Software Architecture Pattern]]
|
|
- 연결 이유: Factory Pattern(디자인 패턴)과 설계 규모(Scale), 범위(Scope), 추상화(Abstraction) 수준에서 대비되는 상위 개념입니다 [1, 2].
|
|
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: Factory Pattern이 시스템 전체의 확장성이나 신뢰성을 결정하는 것이 아니라, 이미 정해진 아키텍처(예: 마이크로서비스, 계층형 등) 내부의 작은 단위에서 구현 디테일을 보조한다는 점을 명확히 이해할 수 있습니다 [1, 2].
|
|
|
|
### Deeper Research Questions
|
|
**소스에 관련 정보가 부족합니다.** (제공된 맥락 안에서 도출할 수 있는 최소한의 심층 질문은 다음과 같습니다.)
|
|
|
|
- 소프트웨어 아키텍처 패턴(예: 계층형 아키텍처 또는 마이크로서비스)의 내부 컴포넌트를 구현할 때 Factory Pattern을 적용함으로써 얻을 수 있는 구체적인 코드 재사용의 이점은 무엇인가?
|
|
- 소스에 언급된 디자인 패턴 예시들(Factory, Singleton, Observer, Strategy)은 각각 어떤 미시적(Micro-level) 설계 문제를 해결하기 위해 고안되었으며, 상호 간의 차이점은 무엇인가?
|
|
- (기타 질문은 소스에 관련 정보가 부족합니다.)
|
|
|
|
### Practical Application Contexts
|
|
|
|
- **Implementation:** Factory Pattern은 소프트웨어 개발의 코딩(Coding) 단계에서 개별 모듈이나 클래스 내부의 구현 문제를 해결하기 위한 도구로 구체적으로 적용됩니다 [1, 2].
|
|
- **System Design:** **소스에 관련 정보가 부족합니다.**
|
|
- **Operation / Maintenance:** **소스에 관련 정보가 부족합니다.**
|
|
- **Learning Path:** **소스에 관련 정보가 부족합니다.**
|
|
- **My Project Relevance:** **소스에 관련 정보가 부족합니다.**
|
|
|
|
### Adjacent Topics
|
|
|
|
- [[Singleton Pattern]]
|
|
- 확장 방향: 소스에서 Factory Pattern과 함께 디자인 패턴의 대표적인 예시로 언급되었으며 [1, 2], 객체 지향 프로그래밍 내 생성 패턴(Creational Patterns)의 다른 활용 방식을 비교 조사하는 데 도움이 됩니다.
|
|
- [[Observer Pattern]]
|
|
- 확장 방향: Factory Pattern과 마찬가지로 컴포넌트 내부의 설계 문제를 다루지만, 객체 간의 상태 변화나 행위(Behavioral) 측면을 다루는 디자인 패턴 사례로 확장하여 이해할 수 있습니다 [1, 2].
|
|
|
|
---
|
|
*Last updated: 2026-05-02*
|
|
|
|
---
|
|
|
|
- Related: [[Dependency-Injection|Dependency-Injection]] , Abstract-Factory-Pattern
|
|
- Concept: Encapsulation
|