맨위로가기

소프트웨어 디자인 패턴

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

소프트웨어 디자인 패턴은 소프트웨어 설계 시 재사용 가능한 해결책을 제시하는 개념이다. 1977년 크리스토퍼 알렉산더의 건축 패턴에서 영감을 받아, 1994년 "GoF" (Gang of Four)가 디자인 패턴 책을 출판하면서 컴퓨터 과학 분야에 널리 알려졌다. 디자인 패턴은 생성, 구조, 행동 패턴으로 분류되며, 객체 생성, 클래스/객체 구조 구성, 객체 간 통신을 다룬다. 동시성 문제를 해결하기 위한 동시성 패턴도 존재하며, 액티브 객체, 모니터 객체, 스레드 풀 등이 있다. 디자인 패턴은 코드 재사용성과 가독성을 높이지만, 과도한 사용은 복잡성을 증가시킬 수 있으며, 특정 프로그래밍 언어의 기능 부족을 나타내는 신호일 수도 있다.

광고

더 읽어볼만한 페이지

  • 소프트웨어 개발 - 유스 케이스
    유스 케이스는 시스템과 액터 간 상호작용을 통해 시스템 목표 달성에 기여하는 동작들을 나타내는 요구 사항 캡처, 모델링, 명세 기법으로, 객체 지향 소프트웨어 공학에서 기능 요구 사항을 캡처하는 데 중요한 역할을 하며 다양한 분야에서 활용된다.
  • 소프트웨어 개발 - 사용자 경험 디자인
    사용자 경험 디자인은 인간 공학에 기반하여 제품 또는 서비스와 사용자 간의 상호작용을 설계하는 분야이며, 사용자 조사, 인터랙션 디자인, 사용성 테스트 등을 통해 효율적이고 만족스러운 경험을 제공하는 것을 목표로 한다.
  • 소프트웨어 디자인 패턴 - 모델-뷰-컨트롤러
    모델-뷰-컨트롤러(MVC)는 소프트웨어 디자인 패턴으로, 응용 프로그램을 모델, 뷰, 컨트롤러 세 가지 요소로 분리하여 개발하며, 사용자 인터페이스 개발에서 데이터, 표현 방식, 사용자 입력 처리를 분리해 유지보수성과 확장성을 높이는 데 기여한다.
  • 소프트웨어 디자인 패턴 - 스케줄링 (컴퓨팅)
    스케줄링은 운영 체제가 시스템의 목적과 환경에 맞춰 작업을 관리하는 기법으로, 장기, 중기, 단기 스케줄러를 통해 프로세스를 선택하며, CPU 사용률, 처리량 등을 기준으로 평가하고, FCFS, SJF, RR 등의 알고리즘을 사용한다.

2. 역사

크리스토퍼 알렉산더는 1977년 건축 분야에서 디자인 패턴의 개념을 처음으로 제시하였다.[2] 1987년, 켄트 벡과 워드 커닝햄은 소프트웨어 개발, 특히 패턴 언어에 이 개념을 적용하기 시작했고, 그 해 OOPSLA 콘퍼런스에서 자신들의 연구 결과를 발표했다.[37][38][2][3]

1994년, "GoF" (Gang of Four, 4인방)라고 불리는 에리히 감마, 리처드 헬름, 랄프 존슨, 존 블리시디스가 쓴 ''Design Patterns: Elements of Reusable Object-Oriented Software'' (번역: 디자인 패턴: 재사용 가능한 객체 지향 소프트웨어의 요소) 책이 출판되면서 컴퓨터 과학 분야에서 널리 알려지게 되었다. 같은 해, 첫 번째 패턴 언어 프로그래밍 컨퍼런스가 개최되었고, 이듬해에는 디자인 패턴 문서를 위한 포틀랜드 패턴 저장소가 설립되었다.

GoF는 그들의 책에서 디자인 패턴을 "특정한 디자인 문제를 해결하고, 객체 지향 디자인을 더 유연하고, 우아하며, 궁극적으로 재사용 가능하게 만드는 것"이라고 설명했다. 이들은 숙련된 프로그래머들이 경험을 통해 얻은 문제 해결 패턴을 공유함으로써, 초보 프로그래머들이 더 쉽게 디자인 문제를 해결하고, 성공적인 디자인을 재사용할 수 있도록 돕는다고 말했다.

3. 분류 및 목록

디자인 패턴은 생성 패턴, 구조 패턴, 행동 패턴으로 분류되며, 각 패턴은 특정 목적을 가지고 문제를 해결한다.[2]

디자인 패턴은 1977년 크리스토퍼 알렉산더가 건축 개념으로 처음 제시했으며, 1987년 켄트 벡과 워드 커닝햄이 프로그래밍에 적용하기 시작했다.[2][3] 1994년 "4인조"(GoF)로 불리는 에리히 감마, 리처드 헬름, 랄프 존슨, 존 블리시데스가 쓴 ''Design Patterns: Elements of Reusable Object-Oriented Software'' 책이 출판되면서 컴퓨터 과학 분야에서 널리 알려졌다.

디자인 패턴은 오랫동안 실제 개발에 적용되어 왔지만, 개념의 공식화는 수년 동안 답보 상태에 머물렀다.[4] 소프트웨어 디자인 패턴은 검증된 개발 패러다임을 제공하여 개발 프로세스를 가속화할 수 있다.[5] 또한, 디자인 패턴을 재사용하면 숨겨진 미묘한 문제들을 방지하고,[6] 패턴에 익숙한 사람들의 코드 가독성을 향상시킬 수 있다.

다음은 디자인 패턴의 분류 및 목록이다.

디자인 패턴 분류 및 목록
분류이름설명디자인 패턴코드 컴플리트[14]기타
생성 패턴추상 팩토리구체적인 클래스를 지정하지 않고 관련 있거나 종속된 객체의 패밀리를 생성하기 위한 인터페이스를 제공한다.
빌더복잡한 객체의 생성과 표현을 분리하여, 동일한 생성 프로세스를 통해 다양한 표현을 생성할 수 있도록 한다.
의존성 주입클래스가 객체를 직접 생성하는 대신, 주입기에서 필요한 객체를 받는다.
팩토리 메서드단일 객체를 생성하기 위한 인터페이스를 정의하지만, 서브클래스가 어떤 클래스를 인스턴스화할지 결정하도록 한다. 팩토리 메서드는 클래스가 인스턴스화를 서브클래스에 위임하도록 한다.
지연 초기화객체 생성, 값 계산 또는 기타 비용이 많이 드는 프로세스를 처음 필요할 때까지 지연시키는 전술. GoF 카탈로그에 "가상 프록시"로 나타나며, 이는 프록시 패턴의 구현 전략이다.
멀티톤클래스가 명명된 인스턴스만 갖도록 하고, 이에 대한 전역 접근점을 제공한다.
오브젝트 풀더 이상 사용하지 않는 객체를 재활용하여, 리소스의 비싼 획득과 해제를 방지한다. 커넥션 풀 및 스레드 풀 패턴의 일반화로 간주될 수 있다.
프로토타입프로토타입 인스턴스를 사용하여 생성할 객체의 종류를 지정하고, 기존 객체의 골격에서 새 객체를 생성하여 성능을 향상시키고 메모리 사용량을 최소화한다.
RAII적절한 객체의 수명주기에 리소스를 연결하여 리소스가 제대로 해제되도록 한다.
싱글톤클래스가 하나의 인스턴스만 갖도록 하고, 이에 대한 전역 접근점을 제공한다.
구조 패턴어댑터, 래퍼 또는 변환기클래스의 인터페이스를 클라이언트가 예상하는 다른 인터페이스로 변환한다. 어댑터를 사용하면 호환되지 않는 인터페이스 때문에 함께 작동할 수 없는 클래스를 함께 작동시킬 수 있다. 엔터프라이즈 통합 패턴과 동일한 기능은 변환기이다.
브리지추상화와 구현을 분리하여 두 가지가 독립적으로 변경될 수 있도록 한다.
컴포지트객체를 트리 구조로 구성하여 부분-전체 계층 구조를 나타낸다. 컴포지트를 사용하면 클라이언트가 개별 객체와 객체들의 조합을 동일하게 처리할 수 있다.
데코레이터동일한 인터페이스를 유지하면서 객체에 추가적인 책임을 동적으로 부착한다. 데코레이터는 기능을 확장하기 위해 서브클래싱의 유연한 대안을 제공한다.
위임서브클래싱 대신 구성을 통해 클래스를 확장한다. 객체는 두 번째 객체(위임자)에 위임하여 요청을 처리한다.
확장 객체계층 구조를 변경하지 않고 계층 구조에 기능을 추가한다.
퍼사드서브 시스템의 인터페이스 집합에 통합된 인터페이스를 제공한다. 퍼사드는 서브 시스템을 더 쉽게 사용할 수 있도록 하는 상위 수준의 인터페이스를 정의한다.
플라이웨이트공유를 사용하여 대규모의 유사한 객체를 효율적으로 지원한다.
프론트 컨트롤러이 패턴은 웹 애플리케이션의 설계와 관련이 있다. 요청을 처리하기 위한 중앙 집중식 진입점을 제공한다.
마커클래스에 메타데이터를 연결하기 위한 빈 인터페이스이다.
모듈클래스, 싱글톤, 메서드, 전역적으로 사용되는 여러 관련 요소를 단일 개념적 엔터티로 그룹화한다.
프록시다른 객체를 대신하거나 자리 표시자를 제공하여 해당 객체에 대한 액세스를 제어한다.
트윈[19]트윈은 이 기능을 지원하지 않는 프로그래밍 언어에서 다중 상속을 모델링할 수 있게 해준다.
행동 패턴블랙보드이질적인 데이터 소스를 결합하기 위한 인공지능 패턴 (블랙보드 시스템 참조)
책임 연쇄요청을 처리할 기회를 둘 이상의 객체에 제공하여 요청을 보낸 객체와 이를 받는 객체의 결합을 피한다. 수신 객체를 연결하고, 객체가 처리할 때까지 요청을 체인을 따라 전달한다.
커맨드요청을 객체로 캡슐화하여 다른 요청을 가진 클라이언트의 매개변수화, 요청의 큐잉 또는 로깅을 허용한다. 또한 실행 취소 가능한 연산을 지원한다.
유창한 인터페이스API가 DSL처럼 읽히도록 메서드를 연결하여 설계한다. 각 메서드 호출은 다음 논리적 메서드 호출을 사용할 수 있는 컨텍스트를 반환한다.
인터프리터언어가 주어지면, 해당 문법에 대한 표현과 언어의 문장을 해석하는 데 해당 표현을 사용하는 인터프리터를 정의한다.
반복자기본 표현을 노출하지 않고, 집합 객체의 요소를 순차적으로 접근하는 방법을 제공한다.
중재자객체 집합의 상호 작용 방식을 캡슐화하는 객체를 정의한다. 중재자는 객체가 서로를 명시적으로 참조하지 않도록 하여 느슨한 결합을 촉진하며, 상호 작용이 독립적으로 달라지도록 허용한다.
메멘토캡슐화를 위반하지 않고 객체의 내부 상태를 캡처하여 외부화하여 객체를 나중에 이 상태로 복원할 수 있도록 한다.
널 객체기본 객체를 제공하여 널 참조를 피한다.
옵서버 또는 게시/구독한 객체의 상태 변경이 모든 종속 객체에 알림을 보내고 자동으로 업데이트되도록 하는 객체 간의 일대다 종속성을 정의한다.
서번트클래스 그룹에 대한 공통 기능을 정의한다. 서번트 패턴은 종종 지정된 클래스 집합에 대한 헬퍼 클래스 또는 유틸리티 클래스 구현이라고도 한다. 헬퍼 클래스는 일반적으로 객체가 없으므로 다양한 종류의 클래스 객체에 대해 작동하는 모든 정적 메서드를 갖는다.
명세부울 대수 방식으로 재조합 가능한 비즈니스 로직.
상태객체가 내부 상태가 변경될 때 동작을 변경할 수 있도록 한다. 객체는 클래스를 변경하는 것처럼 보인다.
전략알고리즘 집합을 정의하고 각 알고리즘을 캡슐화하여 교체 가능하게 만든다. 전략을 사용하면 알고리즘이 이를 사용하는 클라이언트와 독립적으로 달라질 수 있다.
템플릿 메서드연산에서 알고리즘의 골격을 정의하고, 일부 단계를 서브클래스로 연기한다. 템플릿 메서드를 사용하면 서브클래스가 알고리즘의 구조를 변경하지 않고도 알고리즘의 특정 단계를 재정의할 수 있다.
방문자클래스 집합의 인스턴스에서 수행할 연산을 나타낸다. 방문자를 사용하면 연산을 수행하는 요소의 클래스를 변경하지 않고도 새로운 연산을 정의할 수 있다.


3. 1. 생성 패턴

생성 패턴은 객체 생성 메커니즘을 추상화하여 코드를 더 유연하고 관리하기 쉽게 만든다. 주요 생성 패턴에는 추상 팩토리, 빌더, 팩토리 메서드, 프로토타입, 싱글턴 등이 있다.

이름설명디자인 패턴에 존재코드 컴플리트[14]에 존재기타
추상 팩토리구체적인 클래스를 지정하지 않고 관련 있거나 종속된 객체의 패밀리를 생성하기 위한 인터페이스를 제공한다.
빌더복잡한 객체의 생성과 표현을 분리하여, 동일한 생성 프로세스를 통해 다양한 표현을 생성할 수 있도록 한다.
의존성 주입클래스가 객체를 직접 생성하는 대신, 주입기에서 필요한 객체를 받는다.
팩토리 메서드단일 객체를 생성하기 위한 인터페이스를 정의하지만, 서브클래스가 어떤 클래스를 인스턴스화할지 결정하도록 한다. 팩토리 메서드는 클래스가 인스턴스화를 서브클래스에 위임하도록 한다.
지연 초기화객체 생성, 값 계산 또는 기타 비용이 많이 드는 프로세스를 처음 필요할 때까지 지연시키는 전술. GoF 카탈로그에 "가상 프록시"로 나타나며, 이는 프록시 패턴의 구현 전략이다.
멀티톤클래스가 명명된 인스턴스만 갖도록 하고, 이에 대한 전역 접근점을 제공한다.
오브젝트 풀더 이상 사용하지 않는 객체를 재활용하여, 리소스의 비싼 획득과 해제를 방지한다. 커넥션 풀 및 스레드 풀 패턴의 일반화로 간주될 수 있다.
프로토타입프로토타입 인스턴스를 사용하여 생성할 객체의 종류를 지정하고, 기존 객체의 골격에서 새 객체를 생성하여 성능을 향상시키고 메모리 사용량을 최소화한다.
자원 획득은 초기화다 (RAII)적절한 객체의 수명주기에 리소스를 연결하여 리소스가 제대로 해제되도록 한다.
싱글턴클래스가 하나의 인스턴스만 갖도록 하고, 이에 대한 전역 접근점을 제공한다.


3. 1. 1. 추상 팩토리 패턴

추상 팩토리는 관련된 일련의 인스턴스를 상황에 따라 적절하게 생성하는 방법을 제공한다. 《디자인 패턴》과 《코드 컴플리트》[39]에서 소개되었다.

이름《디자인 패턴》에서《코드 컴플리트》에서[39]기타
추상 팩토리



위 테이블에서 ``와 ``는 일반 텍스트로 변환되어야 하는 템플릿이므로 제거했다.

3. 1. 2. 빌더 패턴

빌더은 복잡한 객체의 생성 과정을 단계별로 분리하여, 같은 생성 과정에서도 다른 표현을 생성할 수 있게 한다.

패턴 이름개요GoFCode Complete
빌더복합적인 인스턴스의 생성 과정을 숨긴다.

[34]

3. 1. 3. 팩토리 메서드 패턴

팩토리 메서드 패턴은 실제로 생성되는 인스턴스에 의존하지 않고 인스턴스를 생성하는 방법을 제공한다.[39] 객체 생성을 서브클래스에서 처리하도록 위임하는 패턴이다.

이름《디자인 패턴》에서《코드 컴플리트》에서[39]
팩토리 메서드


3. 1. 4. 프로토타입 패턴

프로토타입 패턴은 기존 객체를 복제하여 새로운 객체를 생성하는 방식이다. 《디자인 패턴》에서는 프로토타입 패턴을 소개하지만, 《코드 컴플리트》에서는 다루지 않는다.[39]

패턴 이름개요GoFCode Complete[34]
프로토타입유사한 인스턴스를 생성하기 위해 원본 인스턴스를 복제한다.


3. 1. 5. 싱글톤 패턴

어떤 클래스에 대해 인스턴스가 단일임을 보장한다.[34] 《디자인 패턴》과 《코드 컴플리트》에서 모두 다루는 패턴이다.[39]

패턴 이름개요GoFCode Complete[34]
싱글턴어떤 클래스에 대해 인스턴스가 단일임을 보장한다.


3. 2. 구조 패턴

구조 패턴은 클래스나 객체를 조합하여 더 큰 구조를 만드는 방법을 제공한다.

이름설명디자인 패턴코드 컴플리트[39]기타
어댑터, 래퍼(Wrapper), 변환기(Translator)클래스의 인터페이스를 클라이언트가 예상하는 다른 인터페이스로 변환한다. 어댑터를 사용하면 호환되지 않는 인터페이스 때문에 함께 작동할 수 없는 클래스를 함께 작동시킬 수 있다.
브리지추상화와 구현을 분리하여 두 가지가 독립적으로 변경될 수 있도록 한다.
컴포지트객체를 트리 구조로 구성하여 부분-전체 계층 구조를 나타낸다. 컴포지트를 사용하면 클라이언트가 개별 객체와 객체들의 조합을 동일하게 처리할 수 있다.
데코레이터동일한 인터페이스를 유지하면서 객체에 추가적인 책임을 동적으로 부착한다. 데코레이터는 기능을 확장하기 위해 서브클래싱의 유연한 대안을 제공한다.
퍼사드서브 시스템의 인터페이스 집합에 통합된 인터페이스를 제공한다. 퍼사드는 서브 시스템을 더 쉽게 사용할 수 있도록 하는 상위 수준의 인터페이스를 정의한다.
플라이웨이트공유를 사용하여 대규모의 유사한 객체를 효율적으로 지원한다.
프록시다른 객체를 대신하거나 자리 표시자를 제공하여 해당 객체에 대한 액세스를 제어한다.
확장 객체(Extension object)계층 구조를 변경하지 않고 계층 구조에 기능을 추가한다.
프론트 컨트롤러요청을 처리하기 위한 중앙 집중식 진입점을 제공한다.
마커클래스에 메타데이터를 연결하기 위한 빈 인터페이스이다.
모듈클래스, 싱글톤, 메서드, 전역적으로 사용되는 여러 관련 요소를 단일 개념적 엔터티로 그룹화한다.
트윈[45]트윈은 이 기능을 지원하지 않는 프로그래밍 언어에서 다중 상속을 모델링할 수 있게 해준다.


3. 2. 1. 어댑터 패턴

어댑터 패턴은 호환되지 않는 인터페이스를 가진 클래스들을 함께 사용할 수 있도록 변환하는 디자인 패턴이다. '래퍼(Wrapper)'나 '변환기(Translator)'라고도 불린다.[39] 《디자인 패턴》과 《코드 컴플리트》[39]에서 이 패턴을 다루고 있다.

어댑터 패턴은 원래 관련이 없는 두 클래스를 연결하는 클래스를 만드는 방식으로 동작한다.

3. 2. 2. 브리지 패턴

브리지 패턴은 추상화와 구현을 분리하여 서로 독립적으로 변경할 수 있도록 한다. 클래스 등의 구현과 호출 측 사이의 가교 역할을 하는 클래스를 준비하여, 구현을 은폐한다.[39]

이름《디자인 패턴》에서《코드 컴플리트》에서[39]기타
브리지


3. 2. 3. 컴포지트 패턴

컴포지트 패턴은 객체들을 트리 구조로 구성하여 부분-전체 계층을 표현하며,[39] 재귀적인 구조를 표현한다. 이 패턴은 《디자인 패턴》과 《코드 컴플리트》에서 소개되었다.[39]

3. 2. 4. 데코레이터 패턴

어떤 인스턴스에 대해 동적으로 부가 기능을 추가하는 방식으로 동작한다. Filter라고도 불린다. 《디자인 패턴》과 《코드 컴플리트》에서 소개되었다.[39]

패턴명개요GoFCode Complete
데코레이터어떤 인스턴스에 대해 동적으로 부가 기능을 추가한다. Filter라고도 불린다.


3. 2. 5. 퍼사드 패턴

퍼사드 패턴은 여러 서브 시스템의 창구가 되는 공통 인터페이스를 제공한다. 《디자인 패턴》과 《코드 컴플리트》[39]에서 언급되었다.

퍼사드 패턴 정보
패턴명개요GoFCode Complete
퍼사드여러 서브 시스템의 창구가 되는 공통 인터페이스를 제공한다.


3. 2. 6. 플라이웨이트 패턴

공유를 통해 많은 수의 작은 객체들을 효율적으로 지원한다. 다수의 인스턴스를 공유하여, 인스턴스 구축에 대한 부하를 줄인다.[39]

패턴명디자인 패턴에서코드 컴플리트에서[39]기타
플라이웨이트


3. 2. 7. 프록시 패턴

프록시 패턴은 공통 인터페이스를 가진 인스턴스를 내포하고, 사용자로부터의 접근을 대리한다. Wrapper라고도 불린다.[39]

이름《디자인 패턴》에서《코드 컴플리트》에서[39]기타
프록시


3. 3. 행동 패턴

행동 패턴은 객체 간의 상호 작용 및 책임 분배에 중점을 둔다. 객체들이 어떻게 서로 협력하여 작업을 수행하는지에 대한 다양한 패턴을 제공한다.

《디자인 패턴》과 《코드 컴플리트》에서 공통적으로 언급되는 행동 패턴은 반복자, 옵서버, 전략, 템플릿 메소드이다.[39]

그 외에 주요 행동 패턴은 다음과 같다:

행동 패턴 분류
이름《디자인 패턴》에서《코드 컴플리트》에서[39]
책임 연쇄
커맨드
인터프리터
반복자
중재자
메멘토
옵서버
상태
전략
템플릿 메소드
비지터


3. 3. 1. 책임 연쇄 패턴

책임 연쇄 패턴은 요청을 처리할 수 있는 객체들의 연결을 통해 요청을 전달하는 방식이다. 이벤트를 송수신하는 여러 객체를 사슬 형태로 연결하여, 해당 객체들 사이에서 이벤트가 전달되도록 한다.[39]

이름《디자인 패턴》에서《코드 컴플리트》에서[39]기타
책임 연쇄


3. 3. 2. 커맨드 패턴

요청을 객체 형태로 캡슐화하여, 요청을 매개변수화하고 큐에 넣거나 로깅할 수 있게 한다. 여러 다른 조작에 대해 각각 대응하는 객체를 준비하고, 객체를 전환함으로써 조작의 전환을 실현한다.[39]

이름《디자인 패턴》에서《코드 컴플리트》에서[39]기타
커맨드


3. 3. 3. 인터프리터 패턴

특정 언어의 문법을 해석하는 방법을 정의한다. 구문 분석을 위해 문법 규칙을 반영하는 클래스 구조를 만든다.

패턴명개요GoFCode Complete
인터프리터구문 분석을 위해 문법 규칙을 반영하는 클래스 구조를 만든다.


3. 3. 4. 반복자 패턴

반복자는 여러 요소를 내포하는 객체의 모든 요소에 대해 순서대로 접근하는 방법을 제공한다.[39]

패턴명개요GoFCode Complete
반복자여러 요소를 내포하는 객체의 모든 요소에 대해 순서대로 접근하는 방법을 제공한다.


3. 3. 5. 중재자 패턴

객체 간의 상호 작용을 캡슐화하여 객체들이 서로 직접 참조하지 않도록 한다. 디자인 패턴 책에 소개되어 있다.[39]

패턴명개요GoFCode Complete
중재자(Mediator)객체 간의 상호 작용을 중재하는 객체를 정의하고, 객체 간의 결합도를 낮춘다.


3. 3. 6. 메멘토 패턴

메멘토(Memento) 패턴은 데이터 구조에 대한 일련의 조작 각각을 기록해두고, 이전 상태 복귀 또는 조작 재현이 가능하도록 하는 패턴이다. 《디자인 패턴》에는 소개되어 있지만, 《코드 컴플리트》에는 소개되어 있지 않다.[39]

패턴명개요GoFCode Complete
메멘토(Memento)데이터 구조에 대한 일련의 조작 각각을 기록해두고, 이전 상태의 복귀 또는 조작의 재현이 가능하도록 한다.


3. 3. 7. 옵서버 패턴

옵서버 패턴(발행-구독 모델)은 객체의 상태 변화를 다른 객체들에게 알리는 방법을 정의한다. 인스턴스의 변화를 다른 인스턴스에서 감시할 수 있도록 하며, 리스너라고도 불린다.[39]

패턴명개요GoFCode Complete
옵서버 (발행-구독 모델)인스턴스의 변화를 다른 인스턴스에서 감시할 수 있도록 한다. 리스너라고도 불린다.


3. 3. 8. 상태 패턴

객체의 상태를 변화시킴으로써, 처리 내용을 변경할 수 있도록 한다.[39]

이름《디자인 패턴》에서《코드 컴플리트》에서[39]기타
상태


3. 3. 9. 전략 패턴

데이터 구조에 적용하는 일련의 알고리즘을 캡슐화하여, 알고리즘의 전환을 용이하게 한다.[39]

3. 3. 10. 템플릿 메서드 패턴

템플릿 메서드 패턴은 알고리즘의 골격을 정의하고 일부 단계를 서브클래스에서 구현하도록 하는 패턴이다. 알고리즘의 중간 과정에서 필요한 처리를 추상 메서드에 위임하고, 그 구현을 변경함으로써 처리 내용을 변경할 수 있도록 한다.[39]

이름《디자인 패턴》에서《코드 컴플리트》에서[39]
템플릿 메소드


3. 3. 11. 비지터 패턴

객체 구조를 순회하면서 각 요소에 대해 특정 작업을 수행한다. 디자인 패턴 책에는 소개되어 있지만, 코드 컴플리트 책에는 소개되지 않았다.[39]

비지터 패턴 정보
패턴명개요GoFCode Complete
방문자(Visitor)데이터 구조를 보유하는 클래스와, 그것에 대해 처리를 수행하는 클래스를 분리한다.


4. 동시성 패턴

멀티스레드 환경에서 동시성 문제를 해결하기 위해 고안된 패턴들이다.

패턴 이름《POSA2》[46]기타설명
액티브 오브젝트메서드 실행을 해당 제어 스레드에 있는 메서드 호출에서 분리한다. 비동기 메서드 호출과 요청 처리를 위한 스케줄러를 사용하여 동시성을 도입한다.
Balking객체가 특정 상태에 있을 때만 객체에 대한 작업을 실행한다.
더블 체크 라킹먼저 잠금 기준(잠금 힌트)을 안전하지 않은 방식으로 테스트하여 잠금 획득에 대한 오버헤드를 줄인다. 이 테스트가 성공하는 경우에만 실제 잠금 로직이 진행된다. 일부 언어/하드웨어 조합으로 구현할 때 안전하지 않을 수 있어서 안티 패턴으로 간주될 수 있다.
이벤트 기반 비동기다중 스레드 프로그램에서 발생하는 비동기 패턴의 문제를 해결한다.[22]
가디드 서스펜션(Guarded suspension)작업을 실행하기 전에 잠금을 획득하고 사전 조건을 충족해야 하는 작업을 관리한다.
조인메시지 전달을 통해 동시적, 병렬, 분산 프로그램을 작성하는 방법을 제공한다. 스레드 및 잠금 사용과 비교하여 이는 상위 수준의 프로그래밍 모델이다.
락한 스레드가 리소스에 "잠금"을 걸어 다른 스레드가 해당 리소스에 액세스하거나 수정하지 못하도록 한다.[23]
메시징 디자인 패턴 (MDP)구성 요소와 애플리케이션 간에 정보(메시지)를 교환할 수 있다.
모니터 객체메서드가 상호 배제의 대상이 되는 객체로, 여러 객체가 동시에 사용하려고 시도하는 것을 방지한다.
반응자반응기 객체는 동기적으로 처리해야 하는 리소스에 대한 비동기 인터페이스를 제공한다.
읽기-쓰기 락객체에 대한 동시 읽기 액세스를 허용하지만 쓰기 작업에는 독점적인 액세스가 필요하다.
스케줄러스레드가 단일 스레드 코드를 실행할 수 있는 시점을 명시적으로 제어한다.
스레드 풀여러 작업을 수행하기 위해 여러 개의 스레드가 생성되며, 일반적으로 큐에 정리된다. 일반적으로 스레드보다 작업이 훨씬 많다.
스레드 특화 스토리지스레드에 로컬인 정적 또는 "글로벌" 메모리.


5. 디자인 패턴의 활용과 주의점

디자인 패턴은 검증된 개발 방법을 제공하여 개발 과정을 빠르게 만들 수 있다.[5] 또한, 디자인 패턴을 재사용하면 나중에 심각한 문제를 일으킬 수 있는 미묘한 문제들을 방지할 수 있고,[6] 패턴에 익숙한 사람들에게는 코드의 가독성을 높이는 데 도움이 될 수 있다.

하지만 디자인 패턴을 잘못 사용하면 불필요하게 복잡성이 증가할 수 있다.[31] 예를 들어, FizzBuzzEnterpriseEdition는 디자인 패턴이 과도하게 복잡성을 증가시킨 유머스러운 예시를 제공한다.[32] 디자인 패턴은 유연성을 위해 추가적인 간접 참조 단계를 도입할 수 있는데, 이는 설계를 복잡하게 만들고 런타임 성능을 저하시킬 수 있다.

일부에서는 디자인 패턴이 특정 프로그래밍 언어(자바 또는 C++)의 기능 부족을 나타내는 신호일 수 있다고 주장한다. 피터 노르비그는 『디자인 패턴』 책에 나오는 23가지 패턴 중 16가지가 Lisp 또는 Dylan에서 단순화되거나 제거될 수 있음을 보여주었다.[28] 폴 그레이엄의 에세이 "Revenge of the Nerds"에서도 이와 비슷한 내용을 확인할 수 있다.[30]

『객체 지향 재사용을 위한 디자인 패턴』의 저자들(GoF)은 디자인 패턴이 특정한 디자인 문제를 해결하고, 객체 지향 디자인을 더 유연하고, 우아하며, 재사용 가능하게 만든다고 말한다. 즉, 설계자가 이전의 경험을 바탕으로 성공적인 디자인을 재사용하도록 돕는다는 것이다.

컴퓨터 프로그래밍에서 초보자와 숙련자 사이에는 큰 생산성 차이가 있는데, 이는 경험의 차이에서 비롯된다. 숙련자들은 다양한 난관을 겪고 극복해왔기 때문에 같은 문제에 직면했을 때, 일반적으로 같은 패턴의 해결책에 도달한다. 각 패턴은 프로그래머들 사이에서 여러 번 반복적으로 고안되었으며, 문제 해결을 위한 전형적인 해결책이다. 또한, 문제 해결을 실제로 수행하기 전의 사전 조사로서 매우 유용하며, 패턴에 이름이 붙어 있어 문제나 해결책을 기술하거나 대화 중에 언급하기 쉽다.

디자인 패턴은 자주 사용되는 설계를 일반화한 것이므로, 구체적인 구현을 제공하는 것이 아니라 개념으로서 참조되어야 한다. 즉, 샘플 코드는 구현 예시일 뿐이다.

디자인 패턴이 모든 상황에서 최선의 설계는 아니다. 『Code Complete』와 같은 서적에서는 디자인 패턴을 함부로 적용하는 것은 부적절하며, 부적절한 사용은 코드의 복잡성을 불필요하게 높인다고 주의한다.

몇몇 디자인 패턴은 프로그래밍 언어(예: Java, C++) 기능의 부족을 나타내는 지표라고 주장되기도 한다. 컴퓨터 과학자 피터 노빅은 GoF의 디자인 패턴 책의 23개 패턴 중 16개 패턴은 언어에 의한 지원으로 단순화 또는 제거될 수 있음을 Lisp와 Dylan을 사용하여 증명했다.[36]

참조

[1] 서적 Modern C++ Design: Generic Programming and Design Patterns Applied Addison-Wesley 2001
[2] 간행물 Panel on design methodology 1987-10
[3] 간행물 Using Pattern Languages for Object-Oriented Program http://c2.com/doc/oo[...] 1987-09
[4] 보고서 Design Patterns Formalization https://www.research[...] École Nationale Supérieure des Techniques Industrielles et des Mines de Nantes 2003-06
[5] 웹사이트 C# 3.0 Design Patterns: Use the Power of C# 3.0 to Solve Real-World Problems http://msdn.microsof[...] C# Books from O'Reilly Media 2012-05-15
[6] 서적 Software Applications: Concepts, Methodologies, Tools, and Applications: Concepts, Methodologies, Tools, and Applications 2009-03-31
[7] 웹사이트 Collection of User Interface Design Patterns http://www.cs.helsin[...] University of Helsinki, Dept. of Computer Science 2008-01-31
[8] 학술지 Software Design Patterns for Information Visualization http://vis.berkeley.[...] 2006
[9] 서적 Secure Design Patterns http://www.cert.org/[...] Software Engineering Institute 2009
[10] 학위논문 Design Principles and Patterns for Computer Systems That Are Simultaneously Secure and Usable http://www.simson.ne[...] 2005
[11] 웹사이트 Yahoo! Design Pattern Library http://developer.yah[...] 2008-01-31
[12] 웹사이트 How to design your Business Model as a Lean Startup? http://torgronsund.w[...] 2010-01-06
[13] 문서 Pattern Languages of Programming, Conference proceedings (annual, 1994—) http://hillside.net/[...]
[14] 서적 Code Complete Microsoft Press 2004-06
[15] 서적 Patterns of Enterprise Application Architecture http://martinfowler.[...] Addison-Wesley
[16] 서적 Core J2EE Patterns: Best Practices and Design Strategies http://www.corej2eep[...] Prentice Hall
[17] 서적 Patterns of Enterprise Application Architecture http://martinfowler.[...] Addison-Wesley
[18] 서적 Effective Java Addison-Wesley
[19] 웹사이트 Twin – A Design Pattern for Modeling Multiple Inheritance http://www.ssw.jku.a[...]
[20] 서적 Pattern-Oriented Software Architecture, Volume 2: Patterns for Concurrent and Networked Objects John Wiley & Sons 2000
[21] 문서 Binding Properties http://c2.com/cgi/wi[...]
[22] 서적 Professional C# 2008 Wiley
[23] 문서 Lock Pattern http://c2.com/cgi/wi[...]
[24] 학술지 ElixirST: A session-based type system for Elixir modules 2023-10
[25] 학술지 Object Interconnections: Comparing Alternative Programming Techniques for Multi-threaded CORBA Servers (Column 7) https://www.dre.vand[...] 1996-07
[26] 웹사이트 A Pattern Definition http://hillside.net/[...] 2007-03-06
[27] 웹사이트 Writing Software Patterns http://www.martinfow[...] 2006-08-01
[28] 간행물 Design Patterns in Dynamic Languages http://www.norvig.co[...]
[29] 간행물 Design pattern implementation in Java and AspectJ
[30] 웹사이트 Revenge of the Nerds http://www.paulgraha[...] 2012-08-11
[31] 서적 Code Complete: A Practical Handbook of Software Construction, 2nd Edition https://archive.org/[...] Pearson Education
[32] 웹사이트 FizzBuzzEnterpriseEdition https://github.com/E[...] 2024-11-19
[33] 학술지 Componentization: The Visitor Example http://se.ethz.ch/~m[...] 2006-07
[34] 서적 Code Complete Microsoft Press
[35] 문서 Lock Pattern http://c2.com/cgi/wi[...]
[36] 간행물 Design Patterns in Dynamic Languages http://www.norvig.co[...]
[37] 콘퍼런스 Panel on design methodology 1987-10
[38] 콘퍼런스 Using Pattern Languages for Object-Oriented Program http://c2.com/doc/oo[...] 1987-09
[39] 서적 Code Complete "[[en:Microsoft Press]]" 2004-06
[40] 서적 Patterns of Enterprise Application Architecture http://martinfowler.[...] "[[en:Addison-Wesley]]"
[41] 서적 Agile Software Development, Principles, Patterns, and Practices
[42] 서적 Core J2EE Patterns: Best Practices and Design Strategies http://www.corej2eep[...] "[[en:Prentice Hall]]"
[43] 서적 Patterns of Enterprise Application Architecture http://martinfowler.[...] "[[en:Addison-Wesley]]"
[44] 서적 Effective Java (Second edition) https://archive.org/[...] Addison-Wesley
[45] 웹인용 Twin – A Design Pattern for Modeling Multiple Inheritance http://www.ssw.jku.a[...]
[46] 서적 Pattern-Oriented Software Architecture, Volume 2: Patterns for Concurrent and Networked Objects https://archive.org/[...] John Wiley & Sons 2000


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com