Home » 기록하고 기억하고 활용하자. » Software Engineering » Design and Architecture » Software Design Patterns » Classic Design Patterns » GoF

Creational

Creational Design Patterns(생성 디자인 패턴) 는 객체 생성 메커니즘을 다루는 디자인 패턴 분류로, 시스템이 객체를 생성, 구성, 표현하는 방식에 독립성을 제공한다. GoF 에서 정의한 5 가지 패턴 (Singleton, Factory Method, Abstract Factory, Builder, Prototype) 을 포함하며, 객체 생성의 복잡성을 캡슐화하고 유연성을 향상시켜 재사용 가능하고 유지보수가 용이한 소프트웨어 시스템 구축을 지원한다.

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): 런타임 시 동적 객체 생성 기법

실무 구현 연관성

패턴	적용 상황	효과
Factory Method	로그, 메시지 처리 등 특정 구현 객체가 런타임 결정	런타임 유연성 증가
Abstract Factory	UI 테마 세트, DB 드라이버 플랫폼 대응 등	제품군 일관성 유지
Builder	복잡 객체 생성 (예: HTTP 클라이언트, 파일 포맷)	가독성↑, 생성 옵션 구조화
Prototype	비용이 큰 객체 복제 시 (예: 게임 엔티티 복제)	복제 간편, 런타임 구성 가능
Singleton	전역 설정, 로깅, 캐시, DB 연결 등	전역 접근성, 자원 절약 효과

주요 기능 및 역할

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

특징

핵심 특징:

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

기술적 특징:

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

핵심 원칙

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

생성 패턴의 종류 및 비교

패턴	핵심 개념	주요 특징·장점	사용 시점 / 목적	실무 예시
Singleton	애플리케이션 전체에서 오직 하나의 인스턴스만 존재하도록 보장하고, 전역 접근 지점 제공	• 전역 상태 공유 • Lazy Initialization 및 Thread-safe 구현 가능 • 인스턴스 관리 일원화	• 설정, 로그, 캐시 등 하나만 있으면 되는 자원 관리 • DB 연결·커넥션 풀처럼 동시에 여러 곳에서 동일 자원을 요청할 때	데이터베이스 커넥션 풀 관리 객체를 단일 인스턴스로 노출해 다중 스레드가 공유하도록 구성
Factory Method	상위 클래스에 생성 인터페이스를 정의하고, 실제 객체 생성은 하위 클래스가 결정	• 생성 로직을 서브클래스에 위임 → OCP 충실 • 클라이언트 - 코드와 구체 클래스 간 결합 최소화	• OS·플랫폼별로 다른 구현체가 필요한 UI 위젯, 로거 등 • 라이브러리에서 확장 포인트 제공하고 싶을 때	운영체제마다 서로 다른 `Button` 을 반환하도록 하는 크로스 - 플랫폼 GUI 툴킷
Abstract Factory	연관된 객체군(제품 패밀리) 을 일관성 있게 생성하는 상위 인터페이스 제공	• 제품군 간 호환성·일관성 보장 • 클라이언트는 구체 공장·제품 클래스 알 필요 없음	• 테마·브랜드·OS 에 따라 버튼 + 체크박스 + 메뉴 등을 세트로 바꿔야 할 때 • 제품군 교체를 런타임 설정으로 전환하려 할 때	라이트/다크 테마 UI 컴포넌트를 한 번에 교체하는 테마 엔진
Builder	복잡한 객체를 단계별로 조립하고, 동일 공정으로 서로 다른 표현을 생성	• 가독성 높은 단계별 API(플루언트 인터페이스) • 파라미터 폭발·불변 객체 문제 해결 • Director 를 통해 생성 절차 재사용	• 필드가 많은 DTO, JSON, HTML, 그래프 등 복합 구조 생성 • 선택적·반복적 구성 요소가 많은 경우	메서드 체인을 이용해 SELECT·WHERE·ORDER BY 를 조립하는 SQL Query Builder
Prototype	기존 객체를 복제 (clone) 하여 새로운 객체 생성	• 객체 생성 비용·복잡도↓ • 런타임에 타입 몰라도 복제 가능 • 깊은/얕은 복제 전략 선택	• 데이터 - 집약적 초기화가 큰 비용을 차지할 때 • 동적 로딩 플러그인에서 새로운 인스턴스 필요할 때	게임에서 몬스터 템플릿을 미리 생성해 스폰 시마다 복제하여 성능 최적화

비교 분석이 반드시 필요한 패턴 조합

Factory Method vs. Abstract Factory

항목	Factory Method 패턴	Abstract Factory 패턴
패턴 목적	객체 생성을 하위 클래스에게 위임	관련된 객체군 (Family of Products) 을 일관되게 생성
생성 단위	단일 객체	제품군 (예: 버튼 + 체크박스 같이 관련된 UI 컴포넌트)
확장성	새로운 제품 추가 시 서브클래스 확장	제품군 확장은 어렵고 전체 팩토리를 교체해야 함
클라이언트 추상화 수준	객체 생성 방법을 캡슐화 (단일 create 메서드)	제품군 단위로 캡슐화된 여러 개의 create 메서드 제공
사용 예시	다양한 버튼 타입 생성 시 (MacButton, WindowsButton 등)	GUI 툴킷처럼 일관된 UI 구성 요소를 생성할 때 (버튼 + 체크박스 등)
관계성	객체 간 관계 없음	관련 객체들을 함께 생성 (일관된 인터페이스 제공 목적)
패턴 복잡도	상대적으로 단순	구조가 복잡하고 팩토리 클래스가 여러 개 필요
대표 인터페이스	`Creator.createProduct()`	`Factory.createButton()`, `Factory.createCheckbox()` 등
주요 구현 방식	Creator 클래스를 상속하여 구현	인터페이스 기반의 팩토리 + 제품 인터페이스 집합 구성

Factory Method 는 단일 객체 생성을 확장 가능하게 설계하는 데 유리하며, 단일 책임 원칙 (SRP) 에 잘 부합한다.
Abstract Factory 는 서로 관련된 객체들을 일관되게 생성해야 할 때 적합하며, 제품군 간의 일관성 유지가 중요한 경우 유리하다.
구조적으로 Abstract Factory 는 Factory Method 를 내부에서 사용할 수도 있음. 즉, 조합도 가능하다.

Factory Method 예시

 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
27
28
29
30
31
32
33
34
35
36
37
38
39
# 제품 인터페이스
class Button:
    def render(self):
        pass

# 구체적인 제품
class WindowsButton(Button):
    def render(self):
        return "Rendering Windows Button"

class MacButton(Button):
    def render(self):
        return "Rendering Mac Button"

# Creator 추상 클래스 (Factory Method 정의)
class Dialog:
    def create_button(self) -> Button:
        pass

    def render_window(self):
        button = self.create_button()
        print(button.render())

# 구체 Creator: Windows
class WindowsDialog(Dialog):
    def create_button(self) -> Button:
        return WindowsButton()

# 구체 Creator: Mac
class MacDialog(Dialog):
    def create_button(self) -> Button:
        return MacButton()

# 클라이언트 코드
def client_code(dialog: Dialog):
    dialog.render_window()

client_code(WindowsDialog())  # Rendering Windows Button
client_code(MacDialog())      # Rendering Mac Button

핵심 포인트: Factory Method 는 하나의 객체 (Button) 생성 책임만 하위 클래스에 위임

Abstract Factory 예시

 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
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
# 제품 인터페이스들
class Button:
    def render(self):
        pass

class Checkbox:
    def check(self):
        pass

# 제품군: Windows
class WindowsButton(Button):
    def render(self):
        return "Rendering Windows Button"

class WindowsCheckbox(Checkbox):
    def check(self):
        return "Checking Windows Checkbox"

# 제품군: Mac
class MacButton(Button):
    def render(self):
        return "Rendering Mac Button"

class MacCheckbox(Checkbox):
    def check(self):
        return "Checking Mac Checkbox"

# 추상 팩토리
class GUIFactory:
    def create_button(self) -> Button:
        pass

    def create_checkbox(self) -> Checkbox:
        pass

# 구체 팩토리: Windows
class WindowsFactory(GUIFactory):
    def create_button(self):
        return WindowsButton()

    def create_checkbox(self):
        return WindowsCheckbox()

# 구체 팩토리: Mac
class MacFactory(GUIFactory):
    def create_button(self):
        return MacButton()

    def create_checkbox(self):
        return MacCheckbox()

# 클라이언트 코드
def client_code(factory: GUIFactory):
    button = factory.create_button()
    checkbox = factory.create_checkbox()
    print(button.render())
    print(checkbox.check())

client_code(WindowsFactory())
client_code(MacFactory())

핵심 포인트: Abstract Factory 는 **관련된 객체군 (Button + Checkbox)**을 함께 생성하여 일관성 유지.

Factory Method vs. Builder

항목	Factory Method 패턴	Builder 패턴
패턴 목적	객체 생성의 책임을 서브클래스에 위임	객체 생성 절차 (단계) 를 캡슐화하여 유연하게 구성
생성 대상	단일 객체 생성	복합 객체 조립 (구성 요소 다양)
생성의 결정 시점	어떤 객체를 만들지 결정 (종류 선택)	어떻게 구성할지 결정 (속성 조합 및 조립)
적용 상황	다양한 타입 중에서 객체 선택이 필요할 때	객체를 여러 단계로 구성하거나 다양한 표현이 필요한 경우
디렉터 사용 여부	일반적으로 사용 안 함	보통 `Director` 가 빌더 단계를 조립함
확장성	제품을 추가하려면 서브클래스만 추가	빌더와 디렉터만 조정하면 다양한 제품 구성 가능
장점	클라이언트 코드에서 구체 클래스 제거 가능	동일한 생성 절차로 다양한 객체 생성 가능
예시 비유	팩토리에서 " 어떤 모델을 주문할지 " 선택	건축가가 집을 지을 때, 벽, 지붕, 창문을 단계별로 조립
결과 객체의 복잡도	일반적으로 단순 (1 개 인스턴스)	일반적으로 복잡 (구성 요소 포함된 객체)

Factory Method 는 무엇을 만들 것인가에 초점을 맞추고, Builder 는 어떻게 만들 것인가에 초점을 맞춘다.

Factory Method 패턴 예시

" 무엇을 만들 것인가?" 를 하위 클래스에 위임 (객체의 종류 선택)

 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
27
28
29
30
31
32
33
34
35
36
37
38
# 제품 인터페이스
class Notification:
    def send(self, message: str):
        pass

# 구체 제품
class EmailNotification(Notification):
    def send(self, message: str):
        print(f"📧 Email sent: {message}")

class SMSNotification(Notification):
    def send(self, message: str):
        print(f"📱 SMS sent: {message}")

# Creator 추상 클래스
class NotificationCreator:
    def create_notification(self) -> Notification:
        pass

    def notify(self, message: str):
        notification = self.create_notification()
        notification.send(message)

# 구체 Creator들
class EmailNotificationCreator(NotificationCreator):
    def create_notification(self) -> Notification:
        return EmailNotification()

class SMSNotificationCreator(NotificationCreator):
    def create_notification(self) -> Notification:
        return SMSNotification()

# 클라이언트
def client_code(creator: NotificationCreator):
    creator.notify("Hello, this is a Factory Method test.")

client_code(EmailNotificationCreator())  # Email sent
client_code(SMSNotificationCreator())    # SMS sent

핵심: 어떤 객체를 만들지는 create_notification() 을 통해 서브클래스에서 결정됨

Builder 패턴 예시

" 어떻게 만들 것인가?" 를 단계적으로 캡슐화 (복합 객체 조립)

 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
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
# 복합 객체
class Car:
    def __init__(self):
        self.engine = None
        self.wheels = None
        self.color = None

    def specs(self):
        return f"🚗 Car with {self.engine} engine, {self.wheels} wheels, and {self.color} color."

# Builder 인터페이스
class CarBuilder:
    def set_engine(self): pass
    def set_wheels(self): pass
    def set_color(self): pass
    def get_result(self): pass

# 구체 Builder
class SportsCarBuilder(CarBuilder):
    def __init__(self):
        self.car = Car()

    def set_engine(self):
        self.car.engine = "V8"

    def set_wheels(self):
        self.car.wheels = 4

    def set_color(self):
        self.car.color = "Red"

    def get_result(self):
        return self.car

# Director
class CarDirector:
    def __init__(self, builder: CarBuilder):
        self.builder = builder

    def construct(self):
        self.builder.set_engine()
        self.builder.set_wheels()
        self.builder.set_color()
        return self.builder.get_result()

# 클라이언트
builder = SportsCarBuilder()
director = CarDirector(builder)
car = director.construct()
print(car.specs())

핵심: 객체의 구성 방식 (엔진, 휠, 색상 등) 을 빌더가 단계적으로 설정하며 조립

Prototype Vs Builder

항목	Prototype 패턴	Builder 패턴
패턴 목적	기존 객체를 복제하여 새로운 객체 생성	객체를 단계적으로 구성하여 유연하게 생성
생성 방식	`clone()` 메서드 기반 깊은 복사 / 얕은 복사	`Director` 를 통해 Builder 단계를 순차적으로 호출
사용 상황	동일한 설정을 가진 객체가 자주 반복적으로 필요할 때	다양한 속성 조합이 가능한 복잡한 객체를 구성해야 할 때
객체 복잡도	비교적 단순하거나 사전 정의된 구조	복합 객체 (속성, 파트가 다양하고 구성 순서가 존재함)
유연성	객체 구조는 고정, 값만 다름	구조와 값 모두 유연하게 설정 가능
성능	빠른 생성 (복제 기반)	느리지만 유연함 (조립 기반)
대표 메서드	`.clone()`	`.set_xxx()`, `.build()`
디렉터 존재 여부	없음	일반적으로 `Director` 가 단계 호출
대표 예시	템플릿 문서, UI 컴포넌트, 몬스터 복제 등	차량 생성, 사용자 설정 기반 보고서, 음식 주문 조립 등

Prototype 은 기존 객체를 빠르게 복제하며, Builder 는 조립 순서를 따르는 빌더 구성에 기반한다.
Prototype 은 객체 복제 비용 최적화하며, Builder 는 객체 구성 복잡도 분리 및 제어한다.

Prototype 패턴 예시

" 복사 (Clone) 기반으로 객체 생성 “
설정된 객체를 기반으로 새로운 객체를 빠르게 복제

 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
27
28
import copy

# Prototype 인터페이스
class Document:
    def clone(self):
        pass

# 구체적인 Prototype
class Resume(Document):
    def __init__(self, name, education, experience):
        self.name = name
        self.education = education
        self.experience = experience

    def show(self):
        print(f"📄 Resume: {self.name}, {self.education}, {self.experience}")

    def clone(self):
        return copy.deepcopy(self)

# 클라이언트 코드
original = Resume("현윤", "서울대", "삼성전자")
original.show()

# 복제한 객체
copy1 = original.clone()
copy1.name = "지훈"
copy1.show()

핵심: 기존 객체를 clone() 메서드로 복사하여 빠르게 유사 객체 생성

Builder 패턴 예시

” 단계별로 복합 객체 조립 “
생성 절차를 분리하여 유연하게 다양한 구성으로 객체 생성 가능

 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
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
# 복합 객체
class Resume:
    def __init__(self):
        self.name = None
        self.education = None
        self.experience = None

    def show(self):
        print(f"📄 Resume: {self.name}, {self.education}, {self.experience}")

# Builder 인터페이스
class ResumeBuilder:
    def set_name(self, name): pass
    def set_education(self, education): pass
    def set_experience(self, experience): pass
    def build(self): pass

# 구체 Builder
class ConcreteResumeBuilder(ResumeBuilder):
    def __init__(self):
        self.resume = Resume()

    def set_name(self, name):
        self.resume.name = name

    def set_education(self, education):
        self.resume.education = education

    def set_experience(self, experience):
        self.resume.experience = experience

    def build(self):
        return self.resume

# Director
class ResumeDirector:
    def __init__(self, builder: ResumeBuilder):
        self.builder = builder

    def construct_resume(self, name, education, experience):
        self.builder.set_name(name)
        self.builder.set_education(education)
        self.builder.set_experience(experience)
        return self.builder.build()

# 클라이언트 코드
builder = ConcreteResumeBuilder()
director = ResumeDirector(builder)
resume = director.construct_resume("현윤", "KAIST", "NAVER")
resume.show()

핵심: 객체 생성 로직을 분리하고, 다양한 설정을 적용 가능하게 함

Prototype Vs Factory Method

항목	Prototype Pattern	Factory Method Pattern
목적	객체를 복제 (clone) 하여 생성	객체 생성을 서브클래스에 위임
생성 방법	`clone()` 호출로 기존 객체 복제	`create()` 호출로 새 인스턴스 생성
사용 이유	생성 비용이 크거나, 복잡한 설정의 객체를 빠르게 복제하고자 할 때	객체 생성 로직을 확장 가능하게 만들고자 할 때
유연성	런타임 시점에 객체의 상태를 유지한 채 복제 가능	새로운 타입의 객체를 쉽게 추가 가능
패턴 구조 중심	인스턴스를 복제하는 방식	서브클래스화된 팩토리 메서드로 객체 생성 위임
장점	복잡한 초기화를 피하고 성능 최적화 가능	제품 계열을 유연하게 추가/변경 가능
단점	깊은 복사 이슈, 상태 관리의 어려움	서브클래스가 많아질 수 있음
적합한 상황	캐싱, 템플릿, 초기화된 인스턴스 재사용 등	다양한 파생 클래스가 필요한 경우 (예: UI 구성요소 생성)
예시	문서 템플릿 시스템, 게임 캐릭터 복제	UI 컴포넌트 생성기, 알림 팝업 팩토리 등

Prototype은 객체를 빠르게 복사하고 재사용하고자 할 때 유리하고, Factory Method는 다양한 서브타입 객체를 생성하고자 할 때 확장성과 구조적 유연성을 제공한다.

Prototype Pattern 예시

 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
import copy

# Prototype 인터페이스
class Shape:
    def clone(self):
        return copy.deepcopy(self)

# ConcretePrototype
class Circle(Shape):
    def __init__(self, radius, color):
        self.radius = radius
        self.color = color

    def __str__(self):
        return f"Circle(radius={self.radius}, color={self.color})"

# Client
def main_prototype():
    circle1 = Circle(10, "red")
    circle2 = circle1.clone()  # 객체 복제
    circle2.color = "blue"

    print("Prototype Pattern:")
    print(circle1)  # 원본
    print(circle2)  # 복제본

Factory Method Pattern 예시

 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
27
28
29
30
31
32
33
34
35
36
37
38
# Product 인터페이스
class Shape:
    def draw(self):
        pass

# Concrete Products
class Circle(Shape):
    def draw(self):
        return "Drawing a Circle"

class Square(Shape):
    def draw(self):
        return "Drawing a Square"

# Creator (Factory Method 정의)
class ShapeFactory:
    def create_shape(self):
        raise NotImplementedError

class CircleFactory(ShapeFactory):
    def create_shape(self):
        return Circle()

class SquareFactory(ShapeFactory):
    def create_shape(self):
        return Square()

# Client
def main_factory():
    factory1 = CircleFactory()
    shape1 = factory1.create_shape()

    factory2 = SquareFactory()
    shape2 = factory2.create_shape()

    print("\nFactory Method Pattern:")
    print(shape1.draw())
    print(shape2.draw())

Singleton vs. Factory/Abstract Factory

항목	Singleton 패턴	Factory Method 패턴	Abstract Factory 패턴
주요 목적	단 하나의 객체를 보장	객체 생성 로직을 서브클래스로 캡슐화	관련 객체군을 일관되게 생성
객체 생성 시점	최초 호출 시 1 회만 생성 (지연 초기화 가능)	호출할 때마다 객체 생성	호출할 때마다 관련 객체 각각 생성
객체 수 제한	항상 하나	여러 개 가능	여러 개 가능 (제품군 단위로)
주요 책임	전역 접근 가능한 단일 인스턴스 보장	객체 생성 방식 분리 (유연성 확보)	제품군 단위 생성의 일관성 유지
사용 예	로깅 시스템, DB 연결 풀	다양한 타입의 Notification, Shape 생성	GUI Toolkit(Button, Checkbox 등) 생성
의존성 주입 용이성	낮음 (전역 접근 지향)	중간 수준 (인터페이스를 통한 캡슐화)	높음 (전체 제품군을 통째로 주입 가능)
코드 확장성	낮음 (하나의 클래스 고정)	중간 수준 (서브클래스 확장)	높음 (새로운 제품군 팩토리만 추가)
패턴 구조 복잡도	매우 단순	중간	비교적 복잡 (여러 인터페이스와 클래스 필요)
결과 객체의 다양성	없음 (항상 동일 객체)	존재 (서브클래스마다 다름)	제품군 단위로 다양성 존재

Singleton 은 단 하나의 인스턴스만 필요하고 상태가 공유되어야 하며, Factory Method 는 객체의 생성 종류를 유연하게 확장하고 싶을 때 유용하며, Abstract Factory 은 관련된 객체군을 함께 생성하고 일관성 있게 관리하고 싶을 때 유용하다.

Singleton 패턴 예시

” 단 하나의 인스턴스만 존재 " 하도록 보장하고, 어디서든 접근 가능하게 만듦

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
class Logger:
    _instance = None

    def __new__(cls):
        if cls._instance is None:
            print("🔧 Creating new Logger instance")
            cls._instance = super().__new__(cls)
        return cls._instance

    def log(self, message: str):
        print(f"LOG: {message}")

# 클라이언트
logger1 = Logger()
logger2 = Logger()

logger1.log("Singleton pattern test.")
print(f"logger1 is logger2? {logger1 is logger2}")  # True

핵심: 오직 하나의 Logger 객체만 생성되며, 재사용된다.

Factory Method 패턴 예시

" 객체 생성 책임을 하위 클래스에게 위임 “

 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
27
# 제품 인터페이스
class Notification:
    def send(self, message: str):
        pass

# 구체 제품
class EmailNotification(Notification):
    def send(self, message: str):
        print(f"📧 Email sent: {message}")

# Creator
class NotificationCreator:
    def create_notification(self) -> Notification:
        pass

    def notify(self, message: str):
        notification = self.create_notification()
        notification.send(message)

# 구체 Creator
class EmailNotificationCreator(NotificationCreator):
    def create_notification(self) -> Notification:
        return EmailNotification()

# 클라이언트
creator = EmailNotificationCreator()
creator.notify("Hello from Factory Method")

핵심: 어떤 객체를 만들지는 하위 클래스에서 결정되며, 객체는 필요할 때마다 생성

Abstract Factory 패턴 예시

” 관련된 객체군을 일관되게 생성하는 팩토리 객체 “

 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
27
28
29
30
31
# 제품 인터페이스
class Button:
    def render(self): pass

class Checkbox:
    def check(self): pass

# 구체 제품군: Windows
class WindowsButton(Button):
    def render(self): print("🪟 Rendering Windows Button")

class WindowsCheckbox(Checkbox):
    def check(self): print("🪟 Checking Windows Checkbox")

# 추상 팩토리
class GUIFactory:
    def create_button(self) -> Button: pass
    def create_checkbox(self) -> Checkbox: pass

# 구체 팩토리
class WindowsFactory(GUIFactory):
    def create_button(self): return WindowsButton()
    def create_checkbox(self): return WindowsCheckbox()

# 클라이언트
factory = WindowsFactory()
button = factory.create_button()
checkbox = factory.create_checkbox()

button.render()
checkbox.check()

핵심: 관련된 객체 (Button + Checkbox) 를 함께 생성하여 UI 구성 일관성 확보

장점

구분	항목	설명	원인/특성
장점	유연성	객체 생성 방식을 동적으로 변경할 수 있음	객체 생성 캡슐화
	확장성	새로운 객체 유형을 쉽게 추가할 수 있음	객체 생성 책임 분리
	책임 분리	클라이언트 코드와 객체 생성 코드를 분리하여 복잡성 낮춤	객체 생성 책임 분리
	재사용성	객체 생성 로직을 여러 곳에서 재사용 가능	객체 생성 캡슐화

단점과 문제점 및 해결방안

단점

항목	설명	해결책
복잡성	패턴 적용 시 시스템 복잡성 증가	명확한 인터페이스, 문서화
러닝커브	패턴 이해 및 적용에 학습 필요	교육, 예제 제공

문제점

항목	원인	영향	탐지/진단	예방 방법	해결 방법 및 기법
객체 생성 실패	팩토리 생성 실패	객체 사용 불가	코드 리뷰	팩토리 검증	팩토리 생성 검증
싱글톤 오용	불필요한 싱글톤 적용	확장성 저하	코드 리뷰	필요시만 적용	패턴 선택 재검토

도전 과제

카테고리	핵심 도전 과제	구체적 문제점	대표 해결 전략·모범 사례
설계 · 선택	패턴 선택의 복잡성	• 상황별 적절 패턴 결정 난도 • 과도한 추상화로 코드 가독성 저하	• 요구사항·제약조건 매트릭스 작성 후 의사결정 • 프로토타입으로 타당성 검증 (PoC) • " 패턴 카탈로그 " 와 체크리스트로 오남용 방지
언어 · 플랫폼	언어적 한계·Reflection 의존	• 생성자 오버로드 부족 • 리플렉션·프록시 남용 시 성능·보안 저하	• - 변형 Factory(등록 맵·람다 팩토리) 로 동적 타입 해결 • 메타프로그래밍 대신 코드 생성 (Annotation Processor, Codegen) 활용
동시성 · 안정성	싱글턴 스레드 안전	• 초기화 경합·데드락·중복 생성	• Double-Checked Locking(volatile)·정적 Holder • JVM 이니셜라이저·enum 싱글턴 • DI 컨테이너 Scope 활용
테스트 · 운영	테스트용 교체 (스왑) 곤란	• 생산 코드와 결합 강해 Mock/Stub 주입 어려움	• 팩토리 주입 (Strategy 패턴)·Service Locator 추상화 • Provider 인터페이스 + DI 컨테이너로 런타임 스왑
최신 기술 환경	클라우드·서버리스·MSA 적용	• 인스턴스 생성 주기·스케일 아웃으로 싱글턴 의미 희석 • 무상태 함수형 플랫폼과 충돌	• 컨테이너 당 싱글턴 → Stateless Factory 로 전환 • 외부 스테이트 (예: Config Server, Redis) 활용
성능 최적화	생성 오버헤드·메모리	• 빈번한 객체 생성으로 GC 부하 • 대형 객체 초기화 비용 증가	• 객체 풀링·Flyweight • Lazy Initialization·캐싱 전략 • Builder 단계별 스트림 처리로 중간 객체 감소
메모리 관리	객체 수명 · 누수 통제	• 길게 참조된 객체로 메모리 누수	• 약참조 (Weak/Soft Reference)·Scope 관리 • Prototype + Pooling 혼합으로 수명 제어

실무 사용 예시

도메인/시스템	사용 패턴	적용 목적	구체적 사례 (라이브러리·기술)	주요 효과
인프라‧설정 관리	Singleton	전역 상태·자원 (로그·설정 등) 단일 인스턴스 공유	Log4j `Logger`, 환경 `ConfigurationManager`	인스턴스 일관성, 동시성 안전, 자원 관리 효율
데이터베이스 접근 계층	Abstract Factory	URL·드라이버 종류별 커넥션 객체군 생성	JDBC `DriverManager` → 특정 `Driver` 선택	DB 종속성 최소화, 멀티 - 벤더 확장성
웹 프레임워크	Factory Method	요청 경로·HTTP 메서드에 따른 처리기 동적 생성	Spring MVC `HandlerMapping`(factory method 로 매핑 객체 반환)	모듈화, OCP 준수, 테스트 용이성
UI 테마 시스템	Abstract Factory	버튼·체크박스 등 위젯 세트를 통일된 L&F 로 생성	Swing / WPF Look-and-Feel Factory	UI 일관성, 테마 교체 유연성
HTTP 클라이언트	Builder	헤더·쿼리·타임아웃 등 옵션 체인 방식으로 요청 구성	OkHttp `Request.Builder`, Retrofit `Retrofit.Builder`	가독성, 선택적 파라미터 관리, 불변 객체 유지
게임 개발	Prototype	캐릭터·아이템 템플릿을 빠르게 복제해 인스턴스화	Unity `ScriptableObject` 기반 오브젝트 복제	생성 비용 절감, 런타임 성능 향상

활용 사례

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

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

시스템 구성:

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

활용된 패턴들:

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

Workflow:

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

담당 역할:

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 적용: 가독성 좋고 옵션 확장에 유연
❌ 직접 빌드: 파라미터 수 증가 → 코드 복잡, 유지보수 어려움

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

Factory 패턴 적용 사례

시스템 구성:

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

Workflow:

Client 가 Factory 에 객체 생성 요청
Factory 가 Product 생성
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

실무 적용 고려사항

카테고리	고려 항목	설명	권장 사항	주의할 점
설계	패턴 선택 기준	문제 유형과 복잡도에 맞는 패턴 선정 필요	요구사항 분석 후 적절한 패턴만 사용	단순 객체 생성에 과도한 패턴 적용 금지
	추상화 수준 조절	고차 추상화는 유지보수와 협업 난이도 증가 가능	필요 최소한의 추상화, 구조 명확화	과도한 추상화로 인한 코드 난독화
구현	인터페이스 명확화	팩토리·빌더 등 생성자 인터페이스는 명확하고 단순해야 함	기능별 인터페이스 분리, 메서드 체이닝 및 alias 제공	의미 불분명한 메서드 및 중복 로직
	구조적 분리	생성 관련 클래스의 위치·의존성 정리 필요	패키지/모듈 분리, 네이밍 표준화	생성자 클래스와 도메인 로직 혼합 금지
테스트	테스트 용이성 확보	전역 객체나 고정 인스턴스는 테스트를 어렵게 만듦	DI 기반 설계, 팩토리 추상화, Mock 객체 구성	Singleton 남용 시 테스트 격리 어려움
	객체 조합 테스트	다양한 생성 경로와 조합에 대한 테스트 필요	단위/통합 테스트 강화, 테스트 케이스 자동화	테스트 커버리지 부족으로 인한 오류 누락
성능	객체 생성 비용 고려	무거운 객체는 필요 시점에 생성 또는 재사용	Lazy Initialization, 객체 풀링, 캐싱 전략 적용	불필요한 사전 초기화로 인한 메모리 낭비
	메모리 관리	객체 생명주기 명확히 해야 누수 방지 가능	약참조 활용, 불필요 객체 해제, GC 유도 고려	참조 지속으로 인한 GC 회수 실패
유지보수	구조 변경 영향도 최소화	생성 로직 변경 시 시스템 전체에 영향 미치지 않도록 분리 구성	생성 책임 모듈화, OCP 원칙 적용	코드 변경 시 ripple effect 발생 가능
	문서화 및 공유	패턴 사용 이유와 구조는 명확히 공유되어야 협업 가능	UML, README, 주석 등으로 생성 흐름 및 책임 명시	과도한 문서화로 실시간 유지 어려움

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

카테고리	항목	설명	권장사항	주의점
메모리 최적화	객체 풀링	자주 생성되는 객체를 재사용하여 메모리 할당 감소	Object Pool, Reuse 전략 적용	메모리 누수, 동기화 필요
	객체 생성 캐싱	동일 객체 중복 생성을 방지하여 메모리 사용량 절감	객체 Cache 또는 Flyweight 패턴 적용	캐시 갱신 정책, 불일치 이슈
	메모리 프로파일링	생성 및 유지 객체 수 모니터링을 통해 최적화 포인트 도출	실제 운영 환경에서 메모리 사용 모니터링	프로파일링 자체의 오버헤드
성능 최적화	지연 초기화	실제로 필요한 시점에 객체 생성하여 불필요한 리소스 낭비 방지	Lazy Initialization	첫 사용 시점 지연 발생 가능
	팩토리 호출 오버헤드	단순 객체 생성에 복잡한 팩토리 사용은 오히려 성능 저하	직접 생성 또는 경량 팩토리 도입 고려	과도한 추상화 또는 Factory 오용
	복제 비용 관리	프로토타입 패턴 사용 시 깊은 복제는 성능 이슈 유발 가능	얕은 복제 (Shallow Copy) 또는 복제 전략 분리	깊은 복제 시 자원 낭비 가능
동시성 및 안정성	스레드 안전성	멀티스레드 환경에서 객체 공유 시 적절한 동기화 필요	synchronized, volatile, Concurrent 구조 사용	과도한 동기화로 인한 병목
	싱글턴 동기화 전략	동시 초기화 시 race condition 방지 필요	`enum Singleton`, `static inner class`, DCL(Double-Checked Locking)	잘못된 동기화는 예외나 중복 인스턴스 초래
생성 전략 관리	생성 비용 고려	고비용 객체는 매번 새로 생성하지 않도록 주의	Pool, Prototype 전략, Factory 패턴 활용	재사용보다 단순 생성이 더 나은 경우 고려
	불필요한 추상화 제거	단순 객체 생성에 불필요한 추상화 계층 도입 시 성능 오히려 저하	설계 간결화, 간단한 경우 직접 생성 사용	유지보수보다 성능이 중요한 경우만 적용
객체 생명주기 관리	빌더 객체 재사용	Builder 매번 새로 생성하면 GC 부하 증가 가능	재사용 가능한 Builder 설계	재사용 시 내부 상태 초기화 주의
	생성/삭제 시점 최적화	객체를 언제 만들고 제거할 것인지 전략적으로 관리 필요	지연 생성, 비동기 제거, 참조 관리	객체 누수, 참조 카운팅 실패 등

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

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

카테고리	주제	핵심 항목	설명
기술 트렌드	클라우드/서버리스	객체 수명 관리, Stateless 생성	클라우드 환경에서 Singleton, Pool, Lazy Init 등의 생성 전략 재정의 필요
	웹어셈블리 (WASM)	경량 객체 팩토리	WASM 모듈 내 객체 생성 비용을 줄이기 위한 팩토리 최적화
	GraphQL 런타임 처리	동적 스키마 생성 팩토리	GraphQL 스키마를 런타임에 조립하는 동적 팩토리 전략 활용
	함수형 프로그래밍	불변 객체 생성	Immutable 객체 생성을 위한 Builder 변형 활용
아키텍처 접근	도메인 주도 설계 (DDD)	애그리게이트 팩토리	복잡한 도메인 객체 (애그리게이트 루트) 생성을 전담하는 팩토리 적용
	이벤트 소싱	이벤트 기반 빌더	이벤트 로그로부터 객체 상태를 단계적으로 재구성 (Rehydration)
	디자인 패턴 결합	복합 설계 전략	Builder + Prototype, Abstract Factory + Singleton 등 패턴 조합 사용 증가
코드 품질 · 생산성	테스트 자동화	Mock 객체 생성	생성 책임을 분리함으로써 테스트 시 의존성 주입과 Mock 구성 용이
	유지보수성	객체 생성 책임 분리	생성 로직 모듈화를 통해 변경 시 영향도 축소 및 재사용성 증가
조직 운영·교육	팀 협업	패턴 교육·표준화 필요	생성 패턴 적용은 팀 내 공통 이해와 적용 방식 일관화가 중요
	코드 품질 문화	생성 패턴 도입 효과	적절한 생성 패턴은 구조적 품질 향상, 확장성·유지보수성 향상 유도

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

카테고리	주제	간략한 설명
GoF 디자인 패턴	생성 패턴 5 종	Singleton, Factory Method, Abstract Factory, Builder, Prototype 등
생성 패턴과의 비교	구조 패턴 vs. 생성 패턴	구조 패턴은 클래스/객체의 구성, 생성 패턴은 객체 생성 책임을 다룸
객체지향 설계 원칙	DIP, OCP, SRP	생성 패턴은 의존 역전 원칙 (DIP) 및 개방 폐쇄 원칙 (OCP) 과 긴밀히 연관됨
실전 구현 전략	DI 컨테이너와의 연계	Spring, NestJS 등 프레임워크에서 생성 패턴을 어떻게 적용하고 자동화하는지 분석
객체 생명주기 관리	Scope, Lifecycle	Singleton, Request, Session 등 다양한 생명주기를 갖는 객체 생성 관리 전략
테스트 전략	객체 모킹 및 스텁	생성 패턴을 통해 테스트 대역 (Mock, Stub) 객체를 쉽게 주입 가능

카테고리	주제	설명
🧩 핵심 이론	생성 패턴 5 종	Singleton, Factory Method, Abstract Factory, Builder, Prototype 등 주요 생성 패턴 학습
	생성 패턴 vs 구조 패턴	구조 패턴은 객체 구성, 생성 패턴은 객체 생성 책임과 관련됨
	객체 생성 로직의 캡슐화	생성 로직을 분리해 코드 유지보수성과 유연성을 향상
	SOLID 원칙 (특히 DIP, OCP, SRP)	생성 패턴은 의존 역전, 개방 폐쇄, 단일 책임 원칙과 깊은 관련

용어 정리

카테고리	용어	설명
1. 생성 패턴 (GoF Creational Patterns)	Factory Method	객체 생성 로직을 서브클래스에 위임하여 캡슐화하는 패턴
	Abstract Factory	관련된 객체군 (Product Family) 을 일관되게 생성하는 인터페이스 제공
	Builder Pattern	복잡한 객체를 단계별로 구성하여 생성하는 패턴
	Prototype Pattern	기존 객체 (Prototype) 를 복제하여 새로운 객체를 생성
	Singleton Pattern	클래스 인스턴스를 단 하나로 제한하고 전역 접근을 제공
2. 설계 원칙 및 개념	Encapsulate What Varies	변화하는 부분을 캡슐화하여 유연하고 유지보수 가능한 구조 유도
	디커플링 (Decoupling)	구성 요소 간의 결합도를 낮추어 모듈화와 확장성을 확보하는 설계 기법
	객체 생성 메커니즘 (Object Creation Mechanism)	시스템 내에서 객체를 생성하고 초기화하는 다양한 기법 또는 패턴의 총칭
3. 테스트 및 품질 관련	Mock / Stub 객체	테스트 시 실제 객체를 대체하여 사용되는 가짜 객체 (행위 검증용)
	Object Pool (객체 풀)	재사용 가능한 객체를 미리 생성하여 풀로 관리하는 메모리 최적화 패턴
	Lazy Initialization (지연 초기화)	객체가 실제로 필요할 때까지 생성을 지연시키는 초기화 전략
4. 소프트웨어 설계 접근법	DI (Dependency Injection)	객체 간 의존성을 외부에서 주입하여 느슨한 결합과 테스트 용이성 확보
	DDD (Domain-Driven Design)	도메인 모델 중심으로 복잡한 시스템을 설계하는 소프트웨어 접근 방식
5. 배경 및 역사	GoF (Gang of Four)	디자인 패턴을 체계화한 저자 네 명 (Gamma, Helm, Johnson, Vlissides) 을 일컫는 용어로, 디자인 패턴의 표준적 기초 제공

참고 및 출처

종합 가이드 및 이론 정리

실무 적용 및 사례 기반 자료

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

소프트웨어 아키텍처 연계

Factory Method Pattern

Factory Method Pattern Factory Method 패턴은 객체 생성의 책임을 상위 클래스가 아닌 하위 클래스에 위임하여, 클라이언트가 어떤 클래스의 인스턴스를 만들 것인지 모른 채 객체를 생성할 수 있게 한다. 추상 클래스는 인터페이스만 정의하고, 실제 객체 생성을 하위 클래스에서 담당함으로써 확장성과 유연성을 확보한다. GoF 의 23 가지 디자인 패턴 중 가장 널리 사용되는 생성 패턴으로, “Virtual Constructor” 라고도 불린다. 이 패턴은 Creator 와 Product 라는 두 개의 주요 계층구조를 통해 객체 생성 로직을 캡슐화하며, Template Method 패턴과 유사한 구조를 가진다. 프레임워크 설계, UI 컴포넌트 생성, 데이터베이스 연결 관리 등 다양한 영역에서 활용되며, 2025 년 현재 마이크로서비스 아키텍처와 AI/ML 시스템에서 그 중요성이 더욱 부각되고 있다. ...

Singleton Pattern

Singleton Pattern Singleton Pattern 은 클래스의 인스턴스를 하나만 만들고 전역에서 접근할 수 있도록 보장하는 디자인 패턴이다. 일반적으로 정적 메서드를 통해 인스턴스를 생성하며, 생성자 접근 제한 (private constructor), 정적 참조 (static instance), 동기화 처리가 핵심이다. 설정 객체, 로깅 시스템, 캐시, 데이터베이스 커넥션 풀 등 리소스를 공유해야 하는 경우에 자주 사용된다. 다만, 잘못된 사용은 테스트 어려움과 결합도 증가를 초래할 수 있다. 핵심 개념 싱글톤 패턴 (Singleton Pattern) 은 클래스의 인스턴스를 단 하나만 생성하고, 전역적으로 접근할 수 있도록 보장하는 생성 패턴이다. ...

Abstract Factory Pattern

Abstract Factory Pattern Abstract Factory Pattern 는 관련 객체들의 계열 (Product Family) 생성을 추상화하는 패턴으로, 클라이언트는 구체 클래스에 의존하지 않고 팩토리 인터페이스에만 의존해 객체를 생성한다. Abstract Factory 와 Concrete Factory, Abstract Product 와 Concrete Product, Client 로 구성되며, 클라이언트는 Abstract Factory 에 팩토리 구현체를 주입받아 원하는 제품 계열을 생성할 수 있다. 이는 제품 간 일관성 유지, 다양한 제품군 전환, 테스트 유연성 향상 등에 강점을 제공한다. 배경 객체 지향 시스템에서 관련 객체들의 패밀리를 생성해야 할 때, 구체적인 클래스를 명시하면 코드가 환경에 종속되고 확장성이 떨어짐. 이를 해결하기 위해 객체 생성 로직을 추상화하는 패턴이 필요해짐. ...

Builder Pattern

Builder Pattern Builder Pattern 은 복잡한 객체 생성 문제를 해결하는 창조적 디자인 패턴으로, Director, Builder, ConcreteBuilder, Product 의 4 가지 핵심 구성요소를 통해 단계별 객체 구성을 지원한다. 생성자 오버로딩 문제를 해결하고 불변 객체 생성을 가능하게 하며, 플루언트 인터페이스를 통한 메서드 체이닝으로 코드 가독성을 크게 향상시킨다. 현대 프레임워크와 라이브러리에서 널리 활용되고 있다. 배경 Builder Pattern 은 다음과 같은 문제를 해결하기 위해 등장했다: 점층적 생성자 패턴 (Telescoping Constructor Pattern) 의 한계 매개변수가 많아질수록 가독성 저하 매개변수 순서 기억의 어려움 코드 유지보수성 문제 자바빈 패턴 (JavaBeans Pattern) 의 문제점 객체 일관성 (Consistency) 깨짐 불변 객체 생성 불가 스레드 안전성 문제 목적 및 필요성 주요 목적: ...

Prototype Pattern

Prototype Pattern Prototype 패턴은 복잡한 초기화 과정을 거친 객체를 새로 생성하는 대신 기존 인스턴스를 복제하는 방식으로 객체 생성을 추상화합니다. “Prototype” 인터페이스와 이를 구현한 “Concrete Prototype”, 그리고 “Client” 가 핵심 참여자이며, 클라이언트는 clone() 만 호출해 객체를 얻는다. 이로 인해 생성 방식이 은닉되고, 런타임에 동적 객체 구성, 깊은 복제 (deep clone), 프로토타입 관리 (registry) 등 고급 기능을 구현할 수 있다. 배경 프로토타입 패턴은 다음과 같은 배경에서 등장했다: 객체 생성 비용 문제 복잡한 객체 초기화 과정에서 발생하는 성능 병목 현상을 해결하기 위해 등장했다. 특히 데이터베이스 연결, 파일 로딩, 복잡한 계산 등이 포함된 객체 생성 시 유용하다. ...

Creational#

배경 및 필요성#

목적 및 필요성#

핵심 개념#

기본 개념#

심화 개념#

실무 구현 연관성#

주요 기능 및 역할#

특징#

핵심 원칙#

생성 패턴의 종류 및 비교#

비교 분석이 반드시 필요한 패턴 조합#

Factory Method vs. Abstract Factory#

Factory Method 예시#

Abstract Factory 예시#

Factory Method vs. Builder#

Factory Method 패턴 예시#

Builder 패턴 예시#

Prototype Vs Builder#

Prototype 패턴 예시#

Builder 패턴 예시#

Prototype Vs Factory Method#

Prototype Pattern 예시#

Factory Method Pattern 예시#

Singleton vs. Factory/Abstract Factory#

Singleton 패턴 예시#

Factory Method 패턴 예시#

Abstract Factory 패턴 예시#

장점#

단점과 문제점 및 해결방안#

단점#

문제점#

도전 과제#

실무 사용 예시#

활용 사례#

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

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

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

실무 적용 고려사항#

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

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

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

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

용어 정리#

참고 및 출처#

종합 가이드 및 이론 정리#

실무 적용 및 사례 기반 자료#

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

소프트웨어 아키텍처 연계#

Creational

배경 및 필요성

목적 및 필요성

핵심 개념

기본 개념

심화 개념

실무 구현 연관성

주요 기능 및 역할

특징

핵심 원칙

생성 패턴의 종류 및 비교

비교 분석이 반드시 필요한 패턴 조합

Factory Method vs. Abstract Factory

Factory Method 예시

Abstract Factory 예시

Factory Method vs. Builder

Factory Method 패턴 예시

Builder 패턴 예시

Prototype Vs Builder

Prototype 패턴 예시

Builder 패턴 예시

Prototype Vs Factory Method

Prototype Pattern 예시

Factory Method Pattern 예시

Singleton vs. Factory/Abstract Factory

Singleton 패턴 예시

Factory Method 패턴 예시

Abstract Factory 패턴 예시

장점

단점과 문제점 및 해결방안

단점

문제점

도전 과제

실무 사용 예시

활용 사례

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

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

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

실무 적용 고려사항

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

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

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

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

용어 정리

참고 및 출처

종합 가이드 및 이론 정리

실무 적용 및 사례 기반 자료

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

소프트웨어 아키텍처 연계