03 디자인패턴
03 디자인패턴
1. 디자인패턴
1. 디자인패턴
- 반복되는 설계 문제에 대해 검증된 해결 방법을 정리한 것
- 클래스/객체 구조를 정형화하여 유지보수성과 확장성을 높임
- “이 상황엔 이런 식으로 설계하면 안정적이다”는 공통 패턴
- GOF 패턴은 클래스/객체 단위 설계를 하고, 아키텍처, EIP, 동시성 등의 시스템/서비스 단위 설계를함.
2. 솔리드원칙(SOLID)과 디자인패턴 🔍
- 객체지향 설계에서 코드 품질과 유지보수성을 높이기 위한 5가지 설계 원칙, 디자인 패턴은 SOLID 원칙을 실천하는 구체적인 방법을 제공
- SOLID는 설계의
원칙
이자철학
이고, 디자인 패턴은 그 원칙들을 코드로 구체화하는해결책
이자템플릿
3. 디자인패턴의 적용 🔍
- 디자인 패턴은
서비스 단위
또는문제 단위
로 필요한 곳에 적절히 적용하는 것이 일반적이고, 여러 패턴이 조화롭게 쓰이면서 복잡한 문제를 효과적으로 해결함. - 한 시스템 내에서
- 객체 생성에는 팩토리 패턴,
- 객체 간 관계 조정에는 어댑터 패턴이나 데코레이터 패턴,
- 동작 방식 유연화에는 전략 패턴,
- 의존성 관리는 DI(Dependency Injection)를 쓰는 식
2. 디자인 패턴 종류
- GOF 패턴 (Gang of Four Design Patterns)
- 문제: 객체지향 설계에서 자주 반복되는
객체 생성
,구조
,행위
관련 공통 설계 문제 - 해결방식: 생성, 구조, 행위의 3가지 카테고리로 분류해 객체 생성 방법 추상화, 객체 간 관계 조합, 객체 간 책임 분배 방식을 체계화
- 사용처: 소프트웨어 개발 전반에서 재사용성과 유지보수성을 높이기 위한 객체지향 설계 시 광범위하게 활용됨 (예: 싱글톤, 팩토리, 옵저버, 전략 패턴 등)
- 문제: 객체지향 설계에서 자주 반복되는
- 아키텍처 패턴 (Architectural Patterns)
- 문제: 대규모 시스템의
복잡한 구조
와역할 분담
을 관리하기 어려움 - 해결방식: 시스템을 계층, 모듈, 서비스 단위로 분리하고 상호작용을 정의
- 사용처: 웹 애플리케이션 MVC, 마이크로서비스, 클라우드 기반 분산 시스템
- 문제: 대규모 시스템의
- 엔터프라이즈 통합 패턴 (Enterprise Integration Patterns, EIP)
- 문제: 이기종 시스템 간
데이터 통합
과안정적인 메시지 전달
어려움 - 해결방식: 메시지 채널, 라우터, 필터 등 표준화된 메시징 패턴 적용
- 사용처: Kafka, RabbitMQ 기반 이벤트 처리, 대규모 서비스 연동
- 문제: 이기종 시스템 간
- 동시성 패턴 (Concurrency Patterns)
- 문제: 멀티스레드 환경에서
자원 충돌
과작업 동기화
문제 - 해결방식: 스레드 풀, 프로듀서-컨슈머 등 병렬 처리 및 동기화 구조 설계
- 사용처: 고성능 서버, 비동기 API, 실시간 데이터 처리 시스템
- 문제: 멀티스레드 환경에서
- 의존성 주입 / 제어 역전 패턴 (Dependency Injection / Inversion of Control Patterns)
- 문제: 객체 간 강한 결합으로 인한
유연성 저하
와테스트
어려움 - 해결방식: 객체 생성과 의존성 관리를 외부에서 주입하여 결합도 감소
- 사용처: 스프링 프레임워크, 모듈화된 애플리케이션 개발
- 문제: 객체 간 강한 결합으로 인한
- 실전 유틸리티 패턴 (Utility Patterns / Real-World Patterns)
- 문제:
반복되는 실무 문제
에 대한 간단하고 안정적인 해결책 부족 - 해결방식: 재사용 가능한 유틸리티 패턴으로 안정성과 견고성 강화
- 사용처: 캐싱, 재시도 로직, 장애 대응, Null 처리 등 실무 개발 전반
- 문제:
3. GOF 디자인 패턴
- 생성(Creational) 패턴
- 해결하려는 문제: 객체 생성 방식이 코드 곳곳에 흩어져 있어 유연성이 떨어지고 결합도가 높아짐
- 목적: 객체 생성 책임을 추상화하여 객체 생성 방식을 일관되고 유연하게 관리하기 위함
- 패턴의 종류
패턴 이름 핵심 설명 Singleton 하나의 인스턴스만 존재하게 보장 Factory Method 객체 생성을 서브클래스에 위임 Abstract Factory 관련된 객체 군을 생성 (팩토리들의 팩토리) Builder 복잡한 객체를 단계적으로 생성 Prototype 기존 객체를 복사하여 새로운 객체 생성 - 구조(Structural) 패턴
- 해결하려는 문제: 서로 다른 객체나 클래스의 구조적 차이로 인해 호환성이나 확장성에 문제가 생김
- 목적: 객체와 클래스 간 조합 관계를 구조화하여 시스템을 유연하고 확장 가능하게 만듦
- 패턴의 종류
패턴 이름 | 설명 |
---|---|
Adapter | 서로 다른 인터페이스를 연결 (호환성 확보) |
Bridge | 구현과 추상화를 분리해 독립적 확장 가능 |
Composite | 객체를 트리 구조로 구성, 계층적 구조 처리 |
Decorator | 기존 객체에 기능을 동적으로 추가 |
Facade | 복잡한 서브시스템에 단순한 인터페이스 제공 |
Flyweight | 객체를 공유하여 메모리 절약 |
Proxy | 객체에 대한 접근을 제어하거나 지연 실행 |
- 행위(Behavioral) 패턴
- 해결하려는 문제: 객체 간의 역할 분담이 명확하지 않거나, 복잡한 상호작용을 다루기 어려움
- 목적: 객체 간 커뮤니케이션 방식과 책임 분산을 구조화하여 유연한 행위 흐름을 구현
- 패턴의 종류
패턴 이름 설명 Strategy 알고리즘을 캡슐화해 교체 가능하게 만듦 Observer 상태 변화 시 연관 객체에 자동 알림 Template Method 알고리즘의 구조를 정의하고 세부 구현은 위임 Command 요청을 객체로 캡슐화해 실행, 취소, 큐 처리 State 객체 상태에 따라 동작을 변경 Chain of Responsibility 요청을 처리할 수 있는 객체들로 연결 Mediator 객체 간 직접 연결 대신 중재자를 통해 통신 Iterator 컬렉션 내부 구조를 몰라도 순회 가능 Interpreter 언어 표현식을 해석하는 구조 제공 Memento 객체의 이전 상태를 저장 및 복원 Visitor 객체 구조를 변경하지 않고 기능 추가
4. 디자인 패턴의 선택 🔍
✅ 객체 생성이 복잡하거나, 생성 방식을 유연하게 관리하고 싶을 때
- 싱글톤(Singleton), 팩토리 메서드(Factory Method), 추상 팩토리(Abstract Factory), 빌더(Builder)
- 데이터베이스 연결 객체, UI 컴포넌트 생성, 다양한 제품군 생성 시
✅ 클래스나 객체 구조를 유연하게 조합하고 싶을 때
- 어댑터(Adapter), 데코레이터(Decorator), 프록시(Proxy), 컴포지트(Composite)
- 기존 코드와 호환, 기능 확장, 접근 제어, 트리 구조 구현 시
✅ 객체 간 상호작용이나 책임 분배가 복잡할 때
- 옵저버(Observer), 전략(Strategy), 커맨드(Command), 상태(State)
- 이벤트 처리, 실행 전략 변경, 명령 기록 및 실행 취소, 상태 전환 관리
✅ 여러 서비스가 협력하는 대규모 분산 시스템을 설계할 때
- 마이크로서비스 아키텍처, 이벤트 소싱(Event Sourcing), CQRS, API Gateway
- 대규모 쇼핑몰, 금융 시스템, 실시간 데이터 처리 시스템
✅ 시스템 간 메시지 기반 통신과 통합이 필요할 때
- 메시지 채널(Message Channel), 라우터(Router), 필터(Filter), 집계기(Aggregator)
- Kafka, RabbitMQ 기반 이벤트 처리, 여러 서비스 연동
✅ 비동기 작업이나 멀티스레드 환경에서 안정적 처리가 필요할 때
- 스레드 풀(Thread Pool), 프로듀서-컨슈머(Producer-Consumer), 미래 객체(Future), 리액터(Reactor)
- 고성능 웹 서버, 백그라운드 작업 처리, 비동기 API
✅ 의존성 관리를 쉽고 유연하게 하고 싶을 때
- 의존성 주입(Dependency Injection), 서비스 로케이터(Service Locator)
- 스프링 프레임워크, 테스트용 목(Mock) 객체 주입
5. 디자인 패턴 🔍
- 디자인패턴을 선택할 때는 “문제 → 패턴”의 직접적 맵핑이 아니라, 문제 상황을 정확히 정의하고 해당 문제와 유사한 설계 문제가 있는지 찾고 관련된 여러 디자인 패턴을 비교하여 필요 시 조합하거나 새롭게 설계해서 적용해야 함.
This post is licensed under CC BY 4.0 by the author.