(Factory · Singleton · Builder · Facade · Observer)
SOLID 원칙만으로는 구조를 설명하기 부족할 때,
반복적으로 검증된 설계 해법에 이름을 붙인 것이 디자인 패턴
왜 디자인 패턴이 필요한가
SOLID까지 지켰는데도 이런 문제가 남는다.
- 객체 생성 로직이 너무 복잡하다
- 서브시스템이 커져서 사용하기 어렵다
- 상태 변경을 감지하기 위해 polling을 돌리고 있다
- 코드 의도를 설명하는 데 문장이 길어진다
디자인 패턴 개요 (GoF)
Gang of Four (GoF)
- 실무 개발자 4명이 정리
- 총 23개 패턴
3가지 분류 ⭐
| 분류 | 목적 |
|---|---|
| Creational | 객체 생성 |
| Structural | 객체 구조 |
| Behavioral | 객체 행동 |
1. Factory / Factory Method Pattern
(생성 패턴)
왜 Factory가 필요한가
객체 생성은 단순히 new가 아니다.
- 생성자 인자 세팅
- 내부 객체 생성
- 상태 검증
- 등록 / 초기화
이 로직을 클라이언트가 알게 되면 OCP, DIP가 동시에 깨진다.
Factory의 핵심 아이디어 ⭐
객체 생성 책임을 분리한다
- “어떻게 만드는지”를 숨긴다
- 클라이언트는 “무엇을 원하는지”만 말한다
❌ Factory 없이 생성하는 구조
Car car = new Car(
new Engine(),
new Tire(),
200,
true
);- 생성자 변경 → 모든 호출부 수정
- 테스트 어려움
⭕ Factory 적용 구조
class CarFactory {
static Car createSportCar() {
return new Car(...);
}
}- 생성 변경 → Factory만 수정
- 클라이언트 안정
Factory Method Pattern ⭐⭐⭐⭐⭐
한 단계 더 나아간 Factory
“공장 자체를 추상화한다”
구조 (이름보다 관계가 중요)
Creator ──▶ Product
ConcreteCreator ──▶ ConcreteProduct- Creator는 Product 인터페이스만 앎
- 실제 생성은 서브클래스에서
SOLID와의 연결
- OCP: 새로운 제품 추가 시 기존 코드 수정 ❌
- DIP: 클라이언트 → 추상화 의존
시험/면접 포인트
- “생성 책임을 서브클래스로 위임”
- if 제거가 목적 ❌
- 변경 지점 격리가 목적 ⭕
2. Singleton Pattern
(생성 패턴)
왜 Singleton이 필요한가
어떤 객체는 여러 개 존재하면 논리적으로 틀린다.
- DB Connection Manager
- 설정 관리자
- 프린터 스풀러
핵심 정의 ⭐
프로그램 전체에서 단 하나의 인스턴스만 존재
Singleton의 3대 조건 ⭐⭐⭐
- private 생성자
- private static instance
- public static getInstance()
기본 구조
class Singleton {
private static Singleton instance;
private Singleton() {}
static Singleton getInstance() {
if (instance == null)
instance = new Singleton();
return instance;
}
}자주 나오는 오해 (시험 단골)
- ❌ 객체 참조도 하나다
- ⭕ 참조는 여러 개, 실체 인스턴스는 하나
Singleton의 한계
- 전역 상태 증가
- 테스트 어려움
- 남용 시 DIP 위반 가능
👉 그래서 필요할 때만 사용
3. Monostate Pattern (보완 개념)
아이디어
- 객체는 여러 개 생성 가능
- 상태만 static으로 공유
Singleton vs Monostate
| 구분 | Singleton | Monostate |
|---|---|---|
| 객체 수 | 1 | 여러 개 |
| 상태 | 공유 | 공유 |
| 객체 비교 | 항상 같음 | 다름 |
언제 쓰는가
- 언어/환경 제약
- import 기반 공유 구조
4. Builder Pattern
(생성 패턴)
Builder가 필요한 상황
- 생성자 인자가 많다
- 생성 과정이 단계적이다
- 생성 순서가 중요하다
❌ Builder 없이 생성자 지옥
new User(name, age, address, phone, email, isAdmin);- 인자 순서 실수
- 가독성 최악
Builder 핵심 아이디어 ⭐⭐⭐⭐⭐
“어떻게 만들지”를 객체로 분리
기본 구조
Builder ──▶ Product
Director ──▶ Builder (선택)- Director는 필수 ❌
- Fluent Interface 자주 사용
Builder 예시
User user = UserBuilder()
.name("kim")
.age(20)
.email("a@a.com")
.build();Factory vs Builder (시험 단골)
| 구분 | Factory | Builder |
|---|---|---|
| 초점 | 무엇을 만들지 | 어떻게 만들지 |
| 생성 과정 | 단일 | 단계적 |
| 인자 많을 때 | ❌ | ⭕ |
5. Facade Pattern
(구조 패턴)
문제 상황
서브시스템이 커질수록:
- 클래스 수 증가
- 의존성 증가
- 사용 난이도 상승
Facade의 핵심 ⭐⭐⭐⭐⭐
복잡한 내부 구조를 단순한 인터페이스로 감싼다
❌ Facade 없는 사용
Loader.load();
Preprocessor.run();
Model.train();
Evaluator.eval();⭕ Facade 적용
learning.run();- 내부 변경 → Facade 내부만 수정
- 클라이언트 안정
SOLID와의 연결
- SRP: 책임 분리
- DIP: 클라이언트 → Facade 의존
6. Observer Pattern
(행동 패턴)
왜 Observer가 필요한가
❌ Polling 방식
- 주기적 확인
- 리소스 낭비
- 이벤트 누락 가능
Observer 핵심 아이디어 ⭐⭐⭐⭐⭐
상태 변경 시 자동 통지
구조 (암기)
Subject
├─ register()
├─ remove()
└─ notify()
Observer
└─ update()중요한 설계 포인트 ⭐
- Subject는 Observer 인터페이스만 앎
- 구체 Observer 타입 모름
→ 다형성 기반 구조
대표 예시
- GUI 이벤트 리스너
- 채팅 서버
- 알림 시스템
SOLID와의 연결
- OCP: Observer 추가 시 기존 코드 수정 ❌
- DIP: Subject → Observer 추상화 의존
핵심 개념 요약
강의·시험·실무 공통
- Factory = 생성 책임 분리
- Factory Method = 공장 추상화
- Singleton = 유일 인스턴스
- Builder = 생성 과정 분리
- Facade = 복잡성 은닉
- Observer = 이벤트 기반 구조
헷갈리기 쉬운 부분 정리
| 비교 | 포인트 |
|---|---|
| Factory vs Builder | 무엇 vs 어떻게 |
| Singleton vs Monostate | 객체 수 |
| Polling vs Observer | 수동 vs 자동 |
| Facade vs 단순 클래스 | 책임 범위 |
Studying CS