디자인 패턴 용어집
디자인 패턴 분야의 개념 18개를 한 장에 모았습니다. 객체 생성 설계 · 객체 설계 · 구조 조합 설계 · 데코레이터 패턴 등 — 코드베이스에서 뽑아 뜻과 관계를 정리했습니다.
- 객체 생성 설계
- 생성 규칙과 구체 타입 선택을 호출부에서 떼어 낸다. 생성자에 검증·기본값이 몰리거나 구현체를 바꿔 끼워야 할 때 쓴다
- 객체 설계 (GoF design patterns, 디자인 패턴)
- 계층 안에서 객체를 어떻게 만들고, 어떻게 조합하고, 책임을 어떻게 나눌지 정한다. GoF 디자인 패턴 23개는 생성·구조·행위 세 질문에 대한 이름 붙은 답이다
- 구조 조합 설계
- 이미 있는 객체를 감싸거나 이어 붙여 인터페이스를 맞추고 기능을 더한다. 원본을 고치지 않고 바깥에서 조합한다
- 데코레이터 패턴 (decorator, wrapper)
- 같은 인터페이스를 구현하면서 원본을 안에 품고 앞뒤에 기능을 덧붙인다. 상속 없이 기능을 겹겹이 쌓을 수 있다
- 빌더 패턴 (builder)
- 선택 인자가 많은 객체를 단계별 설정 후 build() 로 만든다. Kotlin 에서는 이름 있는 인자와 기본값이 많은 경우를 대신하고, 외부 라이브러리 빌더를 다룰 때 주로 만난다
- 스펙 패턴 (specification)
- 「이 조건을 만족하나」라는 업무 규칙을 isSatisfiedBy 를 가진 객체로 만든다. 조건을 이름 붙여 재사용하고 and·or 로 조합할 수 있다. GoF 가 아니라 DDD 에서 나온 패턴이다
- 싱글톤 패턴 (singleton)
- 인스턴스를 하나만 두고 전역에서 같은 것을 쓴다. Kotlin 은 object 선언으로 언어가 보장하고, Spring 빈도 기본 스코프가 싱글톤이다. 가변 상태를 두면 동시성 문제가 된다
- 어댑터 패턴 (adapter, wrapper)
- 호환되지 않는 인터페이스를 가운데서 변환해 함께 쓰게 한다. 포트-어댑터 구조의 어댑터가 이 패턴으로 JPA·외부 API 를 포트 모양에 맞춘다
- 옵저버 패턴 (observer, pub/sub, listener)
- 주체가 구독자 목록을 들고 상태가 바뀌면 전부에게 알린다. 주체는 구독자의 구체 타입을 모른다. 프로세스 밖으로 넓히면 pub/sub 가 된다
- 전략 패턴 (strategy, policy)
- 바뀌는 알고리즘을 인터페이스로 빼고 구현체를 주입해 런타임에 교체한다. 같은 매매 엔진이 백테스트·모의·실거래 거래소를 갈아 끼우는 식이다
- 중재자 패턴 (mediator)
- 여러 객체가 서로 직접 부르지 않고 중재자 하나를 통해서만 소통하게 한다. 다대다 참조를 일대다로 줄이는 대신 중재자가 비대해지기 쉽다
- 책임 연쇄 (chain of responsibility, filter chain)
- 처리기들을 사슬로 잇고 각자 처리하거나 다음으로 넘긴다. 서블릿 필터·게이트웨이 필터·인터셉터가 이 구조다
- 추상 팩토리 (abstract factory)
- 서로 어울려야 하는 객체 묶음(예: 같은 테마의 버튼·창)을 만드는 인터페이스를 두고, 구현 팩토리를 바꿔 묶음 전체를 교체한다
- 커맨드 패턴 (command)
- 요청을 값 객체로 만들어 보내고, 큐에 쌓고, 다시 실행할 수 있게 한다. 메시지로 보내는 「재고 예약」 명령이 그 예다
- 템플릿 메서드 (template method)
- 상위 클래스가 처리 순서(골격)를 고정하고 바뀌는 단계만 하위 클래스가 재정의한다. 상속으로 묶이므로 단계가 많아지면 전략 패턴의 조합이 낫다
- 팩토리 메서드 패턴 (factory method, 정적 팩토리 메서드, 팩토리 패턴)
- 객체 생성을 이름 있는 생성 함수나 하위 클래스가 재정의하는 생성 메서드에 맡긴다. 생성자를 숨기고 create·restore 처럼 목적별 진입점을 두면 잘못된 초기 상태를 만들 수 없다
- 프록시 패턴 (proxy, AOP proxy)
- 진짜 객체 앞에 같은 인터페이스의 대리 객체를 두고 접근을 가로챈다. Spring 의 @Transactional·@Cacheable 이 프록시로 동작해서 같은 클래스 안의 내부 호출에는 적용되지 않는다
- 행위 분배 설계
- 알고리즘과 요청 처리 책임을 객체 사이에 나누고, 무엇이 바뀔 수 있는지를 인터페이스 뒤로 숨긴다
다른 분류