[0627] Design Patterns

ㅇㅇㅈ·2025년 6월 29일

생성 패턴

이름설명비고
Singleton Pattern단 하나의 인스턴스만 생성하도록 보장-
Factory Method Pattern객채 생성 방식을 상위 클래스에서 결정하고,
하위 클래스가 구체적인 생성 담당
객체 생성 로직을 캡슐화해 클라이언트와 구체 클래스간의
결합도를 낮추고, 확장성을 높일 수 있음
Abstract Factory Pattern
(추상 팩토리 패턴)
관련 객체들을 일관성 있게 생성할 수 있는 인터페이스 제공제품군 간의 의존성을 낮추고 시스템 전체의 일관성을 유지하면서 제품군을 쉽게 교체 가능
Builder Pattern복잡한 객체 생성 과정을 단계별로 나누어 유연하게 생성가독성을 높이고 다양한 구성 옵션을 유연하게 생성 가능
Prototype Pattern기존 객체를 복제하여 새로운 객체 생성객체 교체 과정이 복잡하거나 객체 생성 비용이 클 때에,
복제 방식을 통해 효율적으로 교체 가능

 

 

구조 패턴

이름설명비고
Adapter Pattern호환되지 않는 인터페이스를 연결해 호환되도록 변환기존 클래스와 클라이언트 간의 인터페이스 차이를 해소해 두 요소가 함께 동작할 수 있도록 중간에 변환 계층을 추가
Bridge Pattern구현부와 추상부를 분리해 독립적으로 확장 가능케 함두 계층을 분리하며 독립적으로 변경 및 확장이 가능하기에 복잡한 계층구조 단순화 가능
Composite Pattern객체들을 트리 구조로 구성해 부분-전체 계층을 동일하게 다룸클라이언트가 단순한 인터페이스로 복잡한 구조를 처리할 수 있음
Decorator Pattern기존 객체에 새로운 기능을 동적으로 추가원본 객체를 변경하지 않기에 다양한 조합으로 기능 추가할 때 유용
Facade Pattern복잡한 시스템에 대한 단순화된 인터페이스 제공여러 가지 서버 시스템을 갖추고 일관된 시스템을 제공하여 사용자의 쉬운 접근이 가능
Flyweight Pattern공유를 통해 대량의 객체를 효율적으로 관리동일하거나 유사한 객체들이 대량으로 생산되었을 때, 내부 상태를 공유하고 외부 상태는 개별적으로 관리하여, 메모리 줄이고 성능 개선
Proxy Pattern접근 제어, 지연 로딩 등을 위해 대리 객체를 사용대리 객체를 통해 클라이언트 요청을 실제 객체 대신 받아서 처리
접근 제어 및 로깅, 패싱, 지원 초기화 등의 다양한 부가 기능 구현 가능

 

 

행동 패턴

이름설명비고
Chain of Responsibility Pattern
(책임 연쇄 패턴)
요청을 연쇄적으로 처리해 책임을 분산
Command Pattern요청을 객체로 캡슐화해 실행 취소, 재실행 등을 가능케 함
Interpreter Pattern언어 문법을 클래스로 표현하고 해석 로직을 정의
Iterator Pattern내부 구조를 노출하지 않고 집합 객체를 순회
Mediator Pattern객체 간 상호작용을 중재 객체가 담당해 복잡도 감소
Memento Pattern객체 상태를 저장하고 복원할 수 있도록 함
Observer Pattern객체 상태 변화에 따라 관련 객체들이 자동으로 갱신
Strategy Pattern알고리즘을 캡슐화해 교체 가능하도록 함
Template Method Pattern알고리즘 골격을 상위 클래스에서 정의하고 하위 클래스가 일부 구현
Visitor Pattern객체 구조를 변경하지 않고 새로운 연산을 추가

 

 


Singleton Pattern (싱글턴 패턴)

오직 하나의 인스턴스만 생성해서, 시스템 전체에서 동일하게 공유하는 패턴.

Spring에서는 Bean의 기본 Scope가 Singleton(싱글턴).
즉, Spring 컨테이너에 하나의 인스턴스만 생성해서 재사용함.

UML/구조

static Singleton instance : 클래스 내부에 유일한 인스턴스를 static으로 보관

Singleton() : 생성자는 private/protected로 외부에서 직접 생성하지 못하게 막음

static Singleton getInstance() : 이미 생성된 인스턴스를 반환하는 static 메서드

 

Template Method Pattern (템플릿 메서드 패턴)

상위(추상) 클래스에서 알고리즘의 구조를 정의하고, 일부 구체적인 내용은 하위 클래스에서 구현하는 패턴.

"틀"만 제공하고, 실제 동작(primitiveOperation1, primitiveOperation2)은 하위에서 결정

UML/구조

AbstractClass(추상클래스):

templateMethod(): 알고리즘의 뼈대를 제공

primitiveOperation1(), primitiveOperation2(): 추상 메서드(하위 클래스에서 구현)

ConcreteClassA/B: 각자 구체 구현 제공

Spring 실제 코드

RestTemplate의 execute() 메소드가 대표적
(여기서 눈물 조금 맺힘)

RestTemplate은 템플릿 역할. 내부에서 공통 로직(요청 보내기, 에러 핸들링 등)을 처리

실제 HTTP 요청 전/후 구체 동작은 Callback(익명 클래스나 람다 등)으로 외부에서 전달 → 커스터마이즈 가능

public <T> T execute(String uriTemplate, HttpMethod method, @Nullable RequestCallback requestCallback, 
                     @Nullable ResponseExtractor<T> responseExtractor, Object... uriVariables) 
                     throws RestClientException {
    URI url = this.getUriTemplateHandler().expand(uriTemplate, uriVariables);
    return (T) this.doExecute(url, uriTemplate, method, requestCallback, responseExtractor);
}
  • 전체 실행 구조(순서)는 템플릿에서 제공
  • 세부 동작은 전달된 콜백으로 구현

싱글턴 패턴: 객체를 하나만 생성해서 모든 곳에서 공유

템플릿 메서드 패턴: 알고리즘의 구조는 부모에서 정의, 세부 동작은 자식/콜백으로 유연하게 변경

0개의 댓글