Creational

Creational

생성 패턴은 객체 생성 방식을 다양한 방법으로 추상화하여, 시스템의 유연성과 확장성을 높이는 디자인 패턴이다.
이러한 패턴은 객체 생성 로직을 별도의 클래스로 분리하거나, 객체 생성을 위한 인터페이스를 제공함으로써, 코드의 결합도를 낮추고, 유지보수성과 테스트 용이성을 향상시킨다.
대표적인 생성 패턴으로는 싱글톤 (Singleton), 팩토리 메서드 (Factory Method), 추상 팩토리 (Abstract Factory), 빌더 (Builder), 프로토타입 (Prototype) 등이 있다. Factory Method는 서브클래스에 생성 책임을 위임하고, Abstract Factory는 관련 객체군을 생성하며, Builder는 복잡 객체를 단계적으로 구성하고, Prototype은 복제 방식을 제공하며, Singleton은 전역 인스턴스를 보장한다.

핵심 개념

생성 디자인 패턴은 객체 생성 로직을 분리하여, 코드의 유연성, 재사용성, 유지보수성을 향상시키는 설계 패턴이다. 이를 통해 객체 생성 과정을 캡슐화하고, 복잡한 생성 로직을 감추며, 다양한 객체 생성 요구를 효율적으로 처리한다.

기본 개념

• 객체 생성 메커니즘 (Object Creation Mechanism): 시스템에서 객체를 생성하는 방법과 절차
• 캡슐화 (Encapsulation): 객체 생성 로직을 숨기고 인터페이스를 통해 접근하는 방식
• 디커플링 (Decoupling): 클라이언트 코드와 구체적인 클래스 간의 결합도 감소
• 추상화 (Abstraction): 구체적인 구현 대신 인터페이스나 추상 클래스 사용

심화 개념

• 객체 지향 설계 원칙 (OOP Design Principles): SOLID 원칙과의 연관성
• 의존성 주입 (Dependency Injection): 현대적 대안으로서의 DI 패턴
• 메타클래스 (Metaclass): 클래스의 클래스 개념을 통한 동적 객체 생성
• 리플렉션 (Reflection): 런타임 시 동적 객체 생성 기법

실무 구현 연관성

배경 및 필요성

• 객체 생성이 단순하지 않고, 다양한 조건, 설정, 리소스 관리가 필요할 때 코드가 복잡해짐.
• 생성 패턴은 이러한 복잡성을 추상화하여, 클라이언트 코드가 객체 생성 방법을 몰라도 사용할 수 있게 한다.

목적 및 필요성

• 객체 생성 책임 분리: 객체 생성 로직을 캡슐화하여, 클라이언트 코드와 객체 생성 코드를 분리한다.
• 유연성: 객체 생성 방식을 동적으로 변경할 수 있다.
• 확장성: 새로운 객체 유형을 쉽게 추가할 수 있다.

주요 기능 및 역할

• 객체 생성 캡슐화: 객체 생성 로직을 패턴으로 구조화한다.
• 객체 생성 책임 분리: 클라이언트 코드와 객체 생성 코드를 분리한다.
• 객체 생성 방식 동적 변경: 객체 생성 방식을 동적으로 변경할 수 있다.

특징

핵심 특징:

• 객체 생성과 사용의 분리
• 구성 (Composition) 중심의 설계
• 인터페이스 기반 상호작용
• 런타임 유연성 제공

기술적 특징:

• 상속보다 합성 선호
• 개방 - 폐쇄 원칙 (Open-Closed Principle) 준수
• 단일 책임 원칙 (Single Responsibility Principle) 적용

핵심 원칙

1. 프로그래밍은 인터페이스에 대해, 구현에 대해서가 아니다
2. 상속보다 객체 합성을 선호하라
3. 변화하는 것을 캡슐화하라
4. 느슨한 결합 (Loose Coupling) 추구

생성 패턴의 종류 및 비교

장점

단점과 문제점 및 해결방안

단점

문제점

도전 과제

실무 사용 예시

활용 사례

사례 1: 전자상거래 플랫폼

시나리오: 대규모 온라인 쇼핑몰 시스템에서 다양한 결제 방식과 배송 옵션을 지원하는 주문 처리 시스템

시스템 구성:

1
2
3
4
5
6
7

[주문 관리자] ─── [결제 처리 팩토리] ─── [신용카드 처리기]
     │                 │                    │
     │                 └─── [페이팔 처리기]   │
     │                                      │
     └─── [배송 서비스 팩토리] ─── [일반 배송]    │
                 │                         │
                 └─── [익일 배송] ──────────┘

활용된 패턴들:

1. Abstract Factory: 결제 처리와 배송 서비스의 패밀리 생성
2. Builder: 복잡한 주문 정보 구성
3. Singleton: 전역 설정 관리자

Workflow:

1. 고객이 주문 생성 요청
2. 주문 빌더가 단계별로 주문 정보 구성
3. Abstract Factory 가 결제 방식에 따른 처리기 생성
4. Singleton 설정 관리자에서 배송 정책 조회
5. 구성된 주문 객체 반환

담당 역할:

• Factory 패턴: 결제 타입별 처리기 동적 생성
• Builder 패턴: 주문의 복잡한 설정 관리
• Singleton 패턴: 시스템 전반의 설정 정보 관리

사례 2: HTTP 클라이언트 구성

문제: GET, POST, 헤더, 쿼리 스트링 등 다양한 옵션의 조합이 필요하기 때문에 Builder 패턴을 사용

적용:

• RequestBuilder 가 메서드 체이닝으로 옵션 설정 제공
• build() 호출 시 Request 객체 완성

시스템 구성 다이어그램:

sequenceDiagram
    participant Client
    participant Builder
    participant Product

    Client->>Builder: new Builder()
    Client->>Builder: setUrl(), setHeader(), setBody()
    Client->>Builder: build()
    Builder-->>Product: complete Request 객체

Builder 사용 여부 효과 비교*:

• ✅ Builder 적용: 가독성 좋고 옵션 확장에 유연
• ❌ 직접 빌드: 파라미터 수 증가 → 코드 복잡, 유지보수 어려움

사례 2: 객체 생성 로직 캡슐화

Factory 패턴 적용 사례

시스템 구성:

• Client → Factory → Product
• Factory 가 Product 생성 담당

Workflow:

1. Client 가 Factory 에 객체 생성 요청
2. Factory 가 Product 생성
3. Client 가 Product 사용

역할:

• 객체 생성 로직을 캡슐화하여, 클라이언트 코드와 객체 생성 코드를 분리
• 유연성과 확장성 향상

차이점:

• 패턴 미적용 시 클라이언트 코드가 객체 생성 로직을 직접 포함
• 패턴 적용 시 객체 생성 로직이 캡슐화되어 유지보수 및 확장성 향상

구현 예시:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

# Factory 패턴 예시
class Product:
    def operation(self):
        pass

class ConcreteProductA(Product):
    def operation(self):
        print("ConcreteProductA operation")

class ConcreteProductB(Product):
    def operation(self):
        print("ConcreteProductB operation")

class Factory:
    def create_product(self, type_):
        if type_ == "A":
            return ConcreteProductA()
        elif type_ == "B":
            return ConcreteProductB()
        else:
            raise ValueError("Unknown type")

# 사용 예시
factory = Factory()
product = factory.create_product("A")
product.operation()  # 출력: ConcreteProductA operation

실무 적용 고려사항

최적화하기 위한 고려사항 및 주의할 점

• 생성 패턴은 다른 디자인 패턴과 결합하여 사용될 수 있다. 예를 들어, Builder 패턴은 Abstract Factory 패턴과 함께 사용되어 복잡한 객체 생성을 더욱 유연하게 할 수 있다. 또한, Prototype 패턴은 Singleton 패턴과 함께 사용되어 객체 복제를 제한할 수 있다.

주제와 관련하여 주목할 내용

11. 하위 주제로 분류한 추가 학습 항목

관련 분야 포함 추가 학습 필요 항목

용어 정리

참고 및 출처

종합 가이드 및 이론 정리

• Creational Design Patterns - Refactoring Guru
• Design Patterns - Wikipedia
• Creational Pattern - Wikipedia
• Factory Method Pattern - Wikipedia
• Builder Pattern - Wikipedia
• Prototype Pattern - Wikipedia
• Singleton Pattern - Wikipedia
• Creational Patterns - SourceMaking
• Creational Design Patterns - GeeksforGeeks
• Introduction to Creational Design Patterns - Baeldung

실무 적용 및 사례 기반 자료

• Gang of Four Design Patterns - DigitalOcean
• Creational Patterns in Practice - Dev.to
• Creational Patterns and Object-Oriented Design - Medium
• Creational Patterns and Extensibility - LinkedIn
• Creational Patterns Maintainability - Java Code Geeks

프레임워크 및 플랫폼 관점 자료

• Spring Docs - Bean Scope
• Microsoft Learn - Common Web App Architectures & Design Patterns
• Gang of Four Design Patterns - Spring Framework Guru

소프트웨어 아키텍처 연계

• Software Architecture Patterns 2025 - Clustox
• InfoQ Software Architecture and Design Trends Report 2025