Software design pattern
소프트웨어 디자인 패턴(software design pattern)은 소프트웨어 공학에서 소프트웨어 디자인에서 특정 문맥에서 공통적으로 발생하는 문제에 대해 재사용 가능한 해결책이다. 소스나 기계 코드로 바로 전환될수 있는 완성된 디자인은 아니며, 다른 상황에 맞게 사용될 수 있는 문제들을 해결하는데에 쓰이는 서술이나 템플릿이다. 디자인 패턴은 프로그래머가 어플리케이션이나 시스템을 디자인할 때 공통된 문제들을 해결하는데에 쓰이는 형식화 된 가장 좋은 관행이다.
Gang of Four
생성 패턴 (Creational Patterns)
- 추상 팩토리 패턴 (Abstract Factory pattern): 구체적인 클래스를 지정하지 않고 관련성을 갖는 객체들의 집합을 생성하거나 서로 독립적인 객체들의 집합을 생성할 수 있는 인터페이스를 제공하는 패턴.
- 빌더 패턴 (Builder pattern): Composite 객체의 생성(construction) 과정과 표현(representation) 방법을 분리하여 동일한 생성 절차에서 서로 다른 표현 결과를 만들 수 있게 하는 패턴.
- 팩토리 메서드 패턴 (Factory Method): 객체를 생성하는 인터페이스는 미리 정의하되, 인스턴스를 만들 클래스의 결정은 서브클래스 쪽에서 내리는 패턴. 클래스의 인스턴스를 만드는 시점을 서브클래스로 미룸.
- 프로토타입 패턴 (Prototype pattern): 생성할 객체의 종류를 명세하는 데에 원형이 되는 예시물을 이용하고, 그 원형을 복사함으로써 새로운 객체를 생성하는 패턴.
- 싱글턴 패턴 (Singleton pattern): 어떤 클래스의 인스턴스는 오직 하나임을 보장하며, 이 인스턴스에 접근할 수 있는 전역적인 접촉점을 제공하는 패턴.
구조 패턴 (Structural Patterns)
- 어댑터 패턴 (Adapter): 클래스의 인터페이스를 사용자가 기대하는 다른 인터페이스로 변환하는 패턴으로, 호환성이 없는 인터페이스 때문에 함께 동작할 수 없는 클래스들이 함께 작동하도록 해 줌.
- 브리지 패턴 (Bridge): 구현부에서 추상층을 분리하여 각자 독립적으로 변형할 수 있게 하는 패턴.
- 합성 패턴 (Composite): 객체들의 관계를 트리 구조로 구성하여 부분 ? 전체 계층을 표현하는 패턴으로, 사용자가 단일 객체와 복합 객체 모두 동일하게 다루도록 할 수 있음
- 데코레이터 패턴 (Decorator): 주어진 상황 및 용도에 따라 어떤 객체에 책임을 덧붙이는 패턴으로, 기능 확장이 필요할 때 서브클래싱 대신 쓸 수 있는 대안이 될 수 있음.
- 파사드 패턴 (Facade): 서브시스템에 있는 인터페이스 집합에 대해서 하나의 통합된 인터페이스를 제공하는 패턴으로, 서브시스템을 좀더 사용하기 편하게 만드는 상위 수준의 인터페이스를 정의함.
- 플라이웨이트 패턴 (Flyweight): 크기가 작은 객체가 여러개 있을 때, 공유를 통해 이들을 효율적으로 지원하는 패턴.
- 프록시 패턴 (Proxy): 어떤 다른 객체로 접근하는 것을 통제하기 위해서 그 객체의 대리자(surrogate) 또는 자리채움자(placeholder)를 제공하는 패턴.
행위 패턴 (Behavioral Patterns)
- 책임연쇄 패턴 (Chain of responsibility): 요청을 처리할 수 있는 기회를 하나 이상의 객체에게 부여하여 요청을 보내는 객체와 그 용청을 받는 객체 사이의 결합을 피하는 패턴. 요청을 받을 수 있는 객체를 연쇄적으로 묶고, 실제 요청을 처리할 객체를 만날 때까지 객체 고리를 따라서 요청을 전달.
- 커맨드 패턴 (Command pattern): 요청을 객체의 형태로 캡슐화하여 서로 요청이 다른 사용자의 매개변수화, 요청 저장 또는 로깅, 그리고 연산의 취소를 지원하게 만드는 패턴.
- 해석자 패턴 (Interpreter pattern): 주어진 언어에 대해, 그 언어의 문법을 위한 표현 수단을 정의하고, 이와 아울러 그 표현 수단을 사용하여 해당 언어로 작성된 문장을 해서하는 해석기를 정의하는 패턴.
- 반복자 패턴 (Iterator pattern): 내부 표현부를 노출하지 않고 어떤 객체 집합에 속한 원소들을 순차적으로 접근할 수 있는 방법을 제공하는 패턴.
- 중개자 패턴 (Mediator pattern): 한 집합에 속해있는 객체들의 상호작용을 캡슐화하는 객체를 정의하는 패턴. 객체들이 직접 서로를 참조하지 않도록 함으로써 객체들 사이의 소결합(loose coupling)을 촉진시키며, 개발자가 객체들의 상호작용을 독립적으로 다양화시킬 수 있게 만듬.
- 메멘토 패턴 (Memento pattern): 캡슐화를 위배하지 않은 채로 어떤 객체의 내부 상태를 잡아내고 실체화시켜, 이후에 해당 객체가 그 상태로 되돌아올 수 있도록 하는 패턴.
- 옵저버 패턴 (Observer pattern): 객체들 사이에 일 대 다의 의존 관계를 정의해 두어, 어떤 객체의 상태가 변할 때 그 객체에 의존성을 가진 가른 객체들이 그 변화를 통지받고 자동으로 갱신될 수 있게 만드는 패턴.
- 상태 패턴 (State pattern): 객체의 내부 상태에 따라 스스로 행동을 변경할수 있게끔 허가하는 패턴으로, 이렇게 하면 객체는 마치 자신의 클래스를 바꾸는 것처럼 보임.
- 전략 패턴 (Strategy pattern): 동일 계열의 알고리즘군을 정의하고, 각각의 알고리즘을 캡슐화하며, 이들을 상호 교환이 가능하도록 만드는 패턴. 알고리즘을 상요하는 사용자와 상관없이 독립적으로 알고리즘을 다양하게 변경할 수 있게 할수 있다.
- 템플릿 메서드 패턴 (Template method pattern): 객체의 연산에는 알고리즘의 뼈대만을 정의하고 각 단계에서 수행할 구체적 처리는 서브클래스 쪽으로 미루는 패턴. 알고리즘의 구조 자체는 그대로 놔둔 채 알고리즘 각 단계의 처리를 서브클래스에서 재정의할 수 있게 함.
- 방문자 패턴 (Visitor pattern): 객체 구조를 이루는 원소에 대해 수행할 연산을 표현하는 패턴. 연산을 적용할 원소의 클래스를 변경하지 않고도 새로운 연산을 정의할 수 있음.
Cloud Design Patterns
이러한 디자인 패턴은 클라우드에서 안정적이고 확장성 있는 안전한 애플리케이션을 빌드하는 데 유용합니다.
패턴 | 요약 | Category |
특사 | 소비자 서비스 또는 애플리케이션을 대신하여 네트워크 요청을 전송하는 도우미 서비스를 만듭니다. | 디자인 및 구현, 운영 효율성 |
손상 방지 레이어 | 현대식 애플리케이션과 레거시 시스템 사이에 외관 또는 어댑터 레이어를 구현합니다. | 디자인 및 구현, 운영 효율성 |
비동기 요청-회신 | 백 엔드 처리는 비동기적이어야 하지만 프런트 엔드에는 여전히 명확한 응답이 필요한 프런트 엔드 호스트에서 백 엔드 처리를 분리합니다. | 메시징 |
프런트 엔드에 대한 백 엔드 | 특정 프런트 엔드 애플리케이션 또는 인터페이스에서 사용할 별도의 백 엔드 서비스를 만듭니다. | 디자인 및 구현 |
격벽 | 하나가 고장 나더라도 나머지는 정상적으로 작동하도록 애플리케이션의 요소를 여러 풀에 격리합니다. | 신뢰성 |
Cache-Aside | 필요할 때 데이터를 데이터 저장소에서 캐시로 로드 | 데이터 관리, 성능 효율성 |
연출 | 중앙 오케스트레이터에 의존하는 대신 각 서비스에서 비즈니스 작업이 처리되는 시기와 방법을 결정하도록 합니다. | 메시징, 성능 효율성 |
원격 서비스 또는 리소스에 연결할 때 해결하는 데 걸리는 시간이 유동적인 오류를 처리합니다. | 신뢰성 | |
클레임 검사 | 큰 메시지를 클레임 검사 및 페이로드로 분할하면 메시지 버스의 과부하를 피할 수 있습니다. | 메시징 |
보정 트랜잭션 | 여러 단계로 나뉘어 있지만 결국에는 일관적인 작업을 정의하는 일련의 단계에서 수행한 작업을 실행 취소합니다. | 신뢰성 |
경쟁 소비자 | 여러 동시 소비자가 동일한 메시징 채널에 수신된 메시지를 처리할 수 있게 해 줍니다. | 메시징 |
컴퓨팅 리소스 통합 | 여러 작업을 단일 계산 단위로 통합합니다. | 디자인 및 구현 |
CQRS | 별도의 인터페이스를 사용하여 데이터를 업데이트하는 작업과 데이터를 읽는 작업을 분리합니다. | 데이터 관리, 디자인 및 구현, 성능 효율성 |
배포 스탬프 | 데이터 저장소를 포함하여 애플리케이션 구성 요소의 여러 독립 복사본을 배치합니다. | 안정성, 성능 효율성 |
이벤트 소싱 | 추가 전용 저장소를 사용하여 도메인의 데이터에 대해 수행된 작업을 설명하는 일련의 이벤트 전체를 기록합니다. | 데이터 관리, 성능 효율성 |
외부 구성 저장소 | 구성 정보를 애플리케이션 배포 패키지에서 중앙 위치로 이동합니다. | 디자인 및 구현, 운영 효율성 |
페더레이션 ID | 외부 ID 공급자에게 인증을 위임합니다. | 보안 |
게이트 키퍼 | 클라이언트와 애플리케이션 또는 서비스 간 브로커 역할을 하며, 요청을 검사 및 정리하고, 요청 및 데이터를 전달하는 전용 호스트 인스턴스를 사용하여 애플리케이션 및 서비스를 보호합니다. | 보안 |
게이트웨이 집계 | 게이트웨이를 사용하여 여러 개별 요청을 단일 요청으로 집계합니다. | 디자인 및 구현, 운영 효율성 |
게이트웨이 오프로딩 | 공유 또는 특수 서비스 기능을 게이트웨이 프록시에 오프로드합니다. | 디자인 및 구현, 운영 효율성 |
게이트웨이 라우팅 | 단일 엔드포인트를 사용하여 요청을 여러 서비스에 라우팅합니다. | 디자인 및 구현, 운영 효율성 |
Geodes | 백 엔드 서비스를 지리적 노드 세트에 배포합니다. 각 노드는 모든 지역의 클라이언트 요청을 처리할 수 있습니다. | 안정성, 운영 효율성 |
상태 엔드포인트 모니터링 | 외부 도구가 노출된 엔드포인트를 통해 주기적으로 액세스할 수 있는 기능 검사를 애플리케이션 내부에 구현합니다. | 안정성, 운영 효율성 |
인덱스 테이블 | 쿼리에서 자주 참조하는 데이터 저장소의 필드에 대한 인덱스를 만듭니다. | 데이터 관리, 성능 효율성 |
리더 선택 | 인스턴스 중 하나를 다른 인스턴스를 관리하는 리더로 선택하여 분산된 애플리케이션의 공동 작업 인스턴스 컬렉션이 수행하는 작업을 조정합니다. | 디자인 및 구현, 신뢰성 |
구체화된 뷰 | 데이터가 필요한 쿼리 작업에 대해 이상적으로 포맷되지 않은 경우 하나 이상의 데이터 저장소에 있는 데이터에 대한 미리 채워진 뷰를 생성합니다. | 데이터 관리, 운영 효율성 |
파이프 및 필터 | 복잡한 처리를 수행하는 작업을 재사용 가능한 일련의 별도 요소로 분류합니다. | 디자인 및 구현, 메시징 |
우선 순위 큐 | 우선 순위가 높은 요청을 우선 순위가 낮은 요청보다 먼저 받아서 처리하도록 서비스로 전송된 요청의 우선 순위를 지정합니다. | 메시징, 성능 효율성 |
게시자/구독자 | 애플리케이션이 발신자와 수신자를 연결하지 않고 여러 관심 있는 소비자에게 이벤트를 비동기적으로 알릴 수 있습니다. | 메시징 |
큐 기반 부하 평준화 | 작업 그리고 그 작업이 일시적인 높은 부하를 부드럽게 처리하기 위해 호출하는 서비스 사이에서 버퍼 역할을 하는 큐를 사용합니다. | 안정성, 메시징, 복원력, 성능 효율성 |
다시 시도 | 이전에 실패한 작업을 투명하게 다시 시도하여 서비스 또는 네트워크 리소스에 연결하려 할 때 애플리케이션을 사용하여 예상된 일시적 오류를 처리합니다. | 신뢰성 |
Scheduler 에이전트 감독자 | 서비스 및 기타 원격 리소스의 분산된 집합에서 일련의 작업을 조정합니다. | 메시징, 신뢰성 |
순차 호위(convoy) | 다른 메시지 그룹의 처리를 차단하지 않고 정의된 순서대로 관련 메시지 세트를 처리합니다. | 메시징 |
분할 | 데이터 저장소를 수평 파티션 또는 분할 집합으로 나눕니다. | 데이터 관리, 성능 효율성 |
사이드카 | 격리 및 캡슐화를 제공하는 별도의 프로세스 또는 컨테이너에 애플리케이션 구성 요소를 배포합니다. | 디자인 및 구현, 운영 효율성 |
정적 콘텐츠 호스팅 | 정적 콘텐츠를 클라이언트에 직접 제공할 수 있는 클라우드 기반 스토리지 서비스에 배포합니다. | 디자인 및 구현, 데이터 관리, 성능 효율성 |
스트랭글러 그림 | 특정 기능을 새로운 애플리케이션 및 서비스로 점진적으로 교체하여 레거시 시스템을 단계적으로 마이그레이션합니다. | 디자인 및 구현, 운영 효율성 |
제한 | 애플리케이션 인스턴스, 개별 테넌트 또는 서비스 전체의 리소스 사용량을 제어합니다. | 안정성, 성능 효율성 |
발레 키 | 클라이언트에 특정 리소스 또는 서비스에 대한 제한된 직접 액세스를 제공하는 토큰 또는 키를 사용합니다. | 데이터 관리, 보안 |
- 데이터 관리
- 데이터 관리는 클라우드 애플리케이션의 핵심 요소이며 대부분의 품질 특성에 영향을 줍니다. 일반적으로 데이터는 성능, 확장성, 가용성 등의 이유로 여러 위치의 여러 서버에 호스팅되며, 이로 인해 다양한 문제가 발생할 수 있습니다. 예를 들어 데이터 일관성을 유지해야 하며, 일반적으로 여러 위치 간에 데이터를 동기화해야 합니다.
- 디자인 및 구현
- 좋은 디자인이 되려면 구성 요소 디자인 및 배포의 일관성, 관리 및 배포 방법이 간단한 유지 관리 용이성, 구성 요소 및 하위 시스템을 다른 애플리케이션 및 다른 시나리오에 사용할 수 있는 재사용 가능성 등의 요소를 고려해야 합니다. 디자인 및 구현 단계에서 결정된 사항은 클라우드에 호스팅되는 애플리케이션과 서비스의 품질 및 총 소유 비용에 엄청난 영향을 미칩니다.
- 메시징
- 클라우드 애플리케이션은 기본적으로 분산되기 때문에 구성 요소와 서비스를 연결하는 메시지 인프라가 필요하며, 가용성을 최대화할 수 있도록 느슨하게 결합된 인프라가 가장 이상적입니다. 널리 사용되는 비동기 메시지는 여러 가지 이점이 있지만 메시지 순서 지정, 포이즌 메시지 관리, 멱등성 같은 문제도 있습니다.
그 밖의 소프트웨어 디자인 패턴
- Model View Controller pattern (MVC)
- Model View Presenter (MVP)
- Model View Viewmodel (MVVM)
- Reactor pattern & Proactor pattern: Event handling
- Half-Sync/Half-Async
- 생산자-소비자 문제 (Producer–consumer problem)
- 잠자는 이발사 문제
- 흡연자 문제
- 독자-저자 문제
- 철학자들의 만찬 문제
- 세마포어
- Entity–component–system (Entity System)
- Monorepo: 다양한 모듈을 여러개의 레포지터리로 관리하지 않고, 하나의 레포지토리로 관리하는 것.
- 발행-구독 모델 (Publish–subscribe pattern)
- Feature-Sliced Design (FSD)
소프트웨어 아키텍처 디자인
관련 내용은 Software architecture 항목에서 확인.
Software Design Patterns
Creational | Abstract factory, Builder, Dependency injection, Factory method, Lazy initialization, Multiton, Object pool, Prototype, RAII, Singleton |
Structural | Adapter, Bridge, Composite, Decorator, Delegation, Facade, Flyweight, Front controller, Marker interface, Module, Proxy, Twin |
Behavioral | Blackboard, Chain of responsibility, Command, Interpreter, Iterator, Mediator, Memento, Null object, Observer, Servant, Specification, State, Strategy, Template method, Visitor |
Functional | Monoid, Functor, Applicative, Monad, Comonad, Free monad, HOF, Currying, Function composition, Closure, Generator |
Concurrency | Active object, Actor, Balking, Barrier, Binding properties, Coroutine, Compute kernel, Double-checked locking, Event-based asynchronous, Fiber, Futex, Futures and promises, Guarded suspension, Immutable object, Join, Lock, Messaging, Monitor, Nuclear, Proactor, Reactor, Read write lock, Scheduler, STM, Thread pool, Thread-local storage |
Architectural | ADR, Active record, Broker, Client–server, CBD, DAO, DTO, DDD, ECB, ECS, EDA, Front controller, Identity map, Interceptor, Implicit invocation, Inversion of control, Model 2, MOM, Microservices, MVA, MVC, MVP, MVVM, Monolithic, Multitier, Naked objects, ORB, P2P, Publish–subscribe, PAC, REST, SOA, Service locator, Specification |
Cloud Distributed | Ambassador, Anti-Corruption Layer, Bulkhead, Cache-Aside, Circuit Breaker, CQRS, Compensating Transaction, Competing Consumers, Compute Resource Consolidation, Event Sourcing, External Configuration Store, Federated Identity, Gatekeeper, Index Table, Leader Election, MapReduce, Materialized View, Pipes, Filters, Priority Queue, Publisher-Subscriber, Queue-Based Load Leveling, Retry, Scheduler Agent Supervisor, Sharding, Sidecar, Strangler, Throttling, Valet Key |
Other | Business delegate, Composite entity, Intercepting filter, Lazy loading, Mangler, Mock object, Type tunnel, Method chaining |
Books | Design Patterns, Enterprise Integration Patterns, Code Complete, POSA |
People | Christopher Alexander, Erich Gamma, Ralph Johnson, John Vlissides, Grady Booch, Kent Beck, Ward Cunningham, Martin Fowler, Robert Martin, Jim Coplien, Douglas Schmidt, Linda Rising |
Communities | The Hillside Group, The Portland Pattern Repository |
See also
- Design pattern
- Software design
- Software design patterns
- Gang of Four (GoF)
- Algorithms
- Software architecture - 소프트웨어 아키텍처 디자인 관련 내용.
- Event driven architecture
- System Architecture
Favorite site
- Wikipedia (en) 소프트웨어 디자인 패턴에 대한 설명
- Design Patterns Quick Reference 1
- Refactoring.Guru - 리팩터링과 디자인 패턴 - Refactoring.Guru는 리팩토링, 디자인 패턴, SOLID 원칙 및 기타 스마트 프로그래밍 주제에 대해 알아야 할 모든 것을 쉽게 찾을 수 있는 자원입니다.
References
-
Designpatternscard.pdf ↩