소프트웨어 설계 패턴

Software design pattern

소프트웨어 엔지니어링에서 소프트웨어 설계 패턴은 소프트웨어 설계의 특정 컨텍스트 내에서 일반적으로 발생하는 문제에 대한 일반적인 재사용 가능한 솔루션입니다.소스 코드나 기계 코드로 직접 변환할 수 있는 완성된 디자인은 아닙니다.오히려 다양한 상황에서 사용할 수 있는 문제를 해결하는 방법에 대한 설명 또는 템플릿입니다.설계 패턴은 프로그래머가 애플리케이션 또는 시스템을 설계할 때 일반적인 문제를 해결하기 위해 사용할 수 있는 형식화된 베스트 프랙티스입니다.

객체 지향 설계 패턴은 일반적으로 관련된 최종 응용 프로그램 클래스 또는 객체를 지정하지 않고 클래스 또는 객체 간의 관계와 상호작용을 보여줍니다.가변 상태를 암시하는 패턴은 기능적 프로그래밍 언어에 적합하지 않을 수 있습니다.일부 패턴은 해결하려는 문제를 해결하기 위한 지원을 내장한 언어에서 불필요하게 렌더링될 수 있습니다.또, 오브젝트 지향 패턴은 오브젝트 지향 이외의 언어에는 적합하지 않습니다.

설계 패턴은 프로그래밍 패러다임과 구체적인 알고리즘의 수준 사이의 중간 컴퓨터 프로그래밍에 대한 구조화된 접근법으로 볼 수 있다.

역사

패턴은 1977년 크리스토퍼 알렉산더가 건축 개념으로 시작한 것입니다 (c.f. "The Pattern of Streets," JORNER OF THE AIP, 1977년 9월, 제32권, 제3호, 페이지 273-278).1987년 Kent Beck와 Ward Cunningham은 프로그래밍, 특히 패턴 언어에 패턴을 적용하는 아이디어를 실험하기 시작했고 그 [1][2]결과물을 그해 OOPSLA 컨퍼런스에서 발표했습니다.그 후 몇 년 동안 벡, 커닝햄, 그리고 다른 사람들이 이 작업을 추적했다.

디자인 패턴은 Design Patterns라는 책 이후 컴퓨터 과학 분야에서 인기를 얻었습니다. 재사용 가능한 객체 지향 소프트웨어의 요소는 1994년에 소위 "4대강" (Gamma 등)에 의해 출판되었습니다.이것들은 종종 "GoF"로 축약됩니다.같은 해, 최초의 패턴 언어 프로그래밍 컨퍼런스가 개최되었고, 이듬해 디자인 패턴의 문서화를 위해 Portland Pattern Repository가 설립되었습니다.그 용어의 범위는 여전히 논쟁의 여지가 있다.디자인 패턴 장르에서 주목할 만한 책은 다음과 같습니다.

  • Gamma, Erich; Helm, Richard; Johnson, Ralph; Vlissides, John (1995). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley. ISBN 978-0-201-63361-0.
  • Brinch Hansen, Per (1995). Studies in Computational Science: Parallel Programming Paradigms. Prentice Hall. ISBN 978-0-13-439324-7.
  • Buschmann, Frank; Meunier, Regine; Rohnert, Hans; Sommerlad, Peter (1996). Pattern-Oriented Software Architecture, Volume 1: A System of Patterns. John Wiley & Sons. ISBN 978-0-471-95869-7.
  • Beck, Kent (1997). Smalltalk Best Practice Patterns. Prentice Hall. ISBN 978-0134769042.
  • Schmidt, Douglas C.; Stal, Michael; Rohnert, Hans; Buschmann, Frank (2000). Pattern-Oriented Software Architecture, Volume 2: Patterns for Concurrent and Networked Objects. John Wiley & Sons. ISBN 978-0-471-60695-6.
  • Fowler, Martin (2002). Patterns of Enterprise Application Architecture. Addison-Wesley. ISBN 978-0-321-12742-6.
  • Hohpe, Gregor; Woolf, Bobby (2003). Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Addison-Wesley. ISBN 978-0-321-20068-6.
  • Freeman, Eric T.; Robson, Elisabeth; Bates, Bert; Sierra, Kathy (2004). Head First Design Patterns. O'Reilly Media. ISBN 978-0-596-00712-6.

디자인 패턴은 오랫동안 실용적으로 적용되어 왔지만 디자인 패턴의 개념의 공식화는 [3]몇 년 동안 지지부진했다.

연습

설계 패턴은 테스트되고 검증된 개발 패러다임을 [4]제공함으로써 개발 프로세스를 가속화할 수 있습니다.효과적인 소프트웨어 설계를 위해서는 구현 후반까지 파악되지 않을 수 있는 문제를 고려해야 합니다.새로 작성된 코드에는 검출에 시간이 걸리는 숨겨진 미묘한 문제가 있는 경우가 많습니다.또, 장래에 큰 문제를 일으키는 경우도 있습니다.설계 패턴을 재사용하면 이러한 미묘한 [5]문제를 방지할 수 있으며, 패턴을 잘 알고 있는 코더나 설계자가 코드를 읽기 쉽게 할 수 있습니다.

유연성을 얻기 위해 설계 패턴은 일반적으로 추가적인 수준의 간접성을 도입합니다.이러한 경우 설계가 복잡해지고 애플리케이션 성능이 저하될 수 있습니다.

정의상 패턴을 사용하는 각 응용 프로그램에 패턴을 새로 프로그래밍해야 합니다.일부 저자는 이를 컴포넌트가 제공하는 소프트웨어 재사용에서 한 발짝 후퇴한 것으로 간주하기 때문에 연구자들은 패턴을 컴포넌트로 전환하기 위해 노력해 왔습니다.Meyer와 Arnout은 [6]시도했던 패턴의 3분의 2를 전체 또는 부분적으로 구성요소화할 수 있었습니다.

소프트웨어 설계 기술은 광범위한 [citation needed]문제에 적용하기가 어렵습니다.설계 패턴은 일반적인 해결책을 제공하며, 특정 문제와 관련된 세부 사항이 필요하지 않은 형식으로 문서화되어 있습니다.

구조.

설계 패턴은 여러 섹션으로 구성되어 있습니다(아래 § 문서 참조).특히 "구조", "참가자" 및 "협력" 섹션이 관심 대상입니다.이 섹션에서는 설계 모티브, 즉 설계 패턴에 의해 기술된 반복적인 문제를 해결하기 위해 개발자가 특정 설계를 복사하고 수정하는 프로토타입 마이크로 아키텍처에 대해 설명합니다.마이크로 아키텍처는 프로그램 구성 요소(클래스, 메서드 등)와 그 관계의 집합입니다.개발자는 설계 패턴에 이 프로토타입 마이크로 아키텍처를 도입하여 사용합니다. 즉, 설계에 포함된 마이크로 아키텍처는 선택된 설계 모티브와 유사한 구조와 구성을 가집니다.

도메인 고유의 패턴

또, 기존의 설계 패턴의 사용이나 도메인 고유의 설계 패턴의 사용을 포함해, 특정의 도메인에서의 설계 패턴을 코드화하기 위한 노력도 행해지고 있습니다.예를 들어 사용자 인터페이스 설계 패턴,[7] 정보 시각화,[8] 안전한 설계,[9] "안전한 사용성",[10] 웹 설계 및 비즈니스 모델 [12]설계가 있습니다.

연례 프로그래밍 회의 절차 패턴 언어에는 도메인 고유의 패턴 예가 많이 포함되어 있습니다.

분류 및 목록

디자인 패턴은 원래 어떤 문제를 해결하느냐에 따라 3가지 하위 분류로 분류되었습니다.회전 패턴은 필수 기준에 따라 제어된 방식으로 객체를 작성할 수 있는 기능을 제공합니다.구조 패턴은 다양한 클래스와 객체를 구성하여 더 큰 구조를 형성하고 새로운 기능을 제공하는 것입니다.마지막으로 행동 패턴은 객체 간의 공통 통신 패턴을 식별하고 이러한 패턴을 실현하는 것입니다.

크레디셔널 패턴

이름. 묘사 디자인 패턴 코드[14] 컴플리트 중 다른.
추상 공장 구체적인 클래스를 지정하지 않고 관련 객체 또는 종속 객체의 패밀리를 작성할 수 있는 인터페이스를 제공합니다. 네. 네. —
빌더 복잡한 객체의 구성을 표현에서 분리하여 동일한 구성 프로세스가 다양한 표현을 생성할 수 있도록 합니다. 네. 아니요. —
의존 관계 주입 클래스는 개체를 직접 만드는 대신 인젝터에서 필요한 개체를 수락합니다. 아니요. 아니요. —
공장법 단일 개체를 만들기 위한 인터페이스를 정의하지만 인스턴스화할 클래스는 하위 클래스가 결정합니다.Factory 메서드를 사용하면 클래스가 하위 클래스로 인스턴스화를 연기할 수 있습니다. 네. 네. —
느린 초기화 오브젝트 작성, 값 계산 또는 기타 비용이 많이 드는 프로세스를 처음 필요할 때까지 지연시키는 방법.이 패턴은 GoF 카탈로그에 프록시 패턴의 구현 전략인 "가상 프록시"로 표시됩니다. 아니요. 아니요. PoEAA[15]
멀티온 클래스에 명명된 인스턴스만 있는지 확인하고 해당 인스턴스에 대한 글로벌 액세스 지점을 제공합니다. 아니요. 아니요. —
오브젝트 풀 더 이상 사용되지 않는 개체를 재활용하여 값비싼 리소스 획득 및 방출을 방지합니다.연결 풀 및 스레드 풀 패턴의 일반화로 간주할 수 있습니다. 아니요. 아니요. —
시제품 프로토타입 인스턴스를 사용하여 생성할 객체의 종류를 지정하고 기존 객체의 '스켈톤'에서 새 객체를 생성함으로써 성능을 향상시키고 메모리 공간을 최소화할 수 있습니다. 네. 아니요. —
자원 취득은 초기화(RAII) 적절한 개체의 수명에 리소스를 연결하여 리소스가 올바르게 해제되었는지 확인하십시오. 아니요. 아니요. —
싱글턴 클래스에 인스턴스가 1개만 있는지 확인하고 해당 인스턴스에 대한 글로벌 액세스 지점을 제공합니다. 네. 네. —

구조 패턴

이름. 묘사 디자인 패턴 코드[14] 컴플리트 중 다른.
어댑터, 래퍼 또는 번역기 클래스의 인터페이스를 클라이언트가 기대하는 다른 인터페이스로 변환합니다.어댑터는 호환되지 않는 인터페이스로 인해 다른 방법으로는 작동하지 않는 클래스를 함께 작동시킵니다.엔터프라이즈 인테그레이션 패턴에 상당하는 것이 번역자입니다. 네. 네. —
다리 추상화를 구현에서 분리하여 두 추상화를 독립적으로 변화시킵니다. 네. 네. —
컴포지트 객체를 트리 구조로 구성하여 부품 전체 계층을 나타냅니다.Composite를 사용하면 클라이언트는 개별 객체와 객체의 구성을 균일하게 처리할 수 있습니다. 네. 네. —
데코레이터 동일한 인터페이스를 동적으로 유지하는 개체에 추가 책임을 부여합니다.데코레이터는 기능을 확장하기 위해 하위 분류 대신 유연한 대체 기능을 제공합니다. 네. 네. —
확장 객체 계층을 변경하지 않고 계층에 기능 추가. 아니요. 아니요. 신속한 변화를 위한 소프트웨어 개발, 원칙, 패턴 및[16] 프랙티스
전면 서브시스템 내의 인터페이스 세트에 통합 인터페이스를 제공합니다.파사드는 하위 시스템을 사용하기 쉽게 하는 상위 수준의 인터페이스를 정의합니다. 네. 네. —
플라이급 공유를 사용하면 다수의 유사한 개체를 효율적으로 지원할 수 있습니다. 네. 아니요. —
전면 컨트롤러 이 패턴은 웹 애플리케이션 설계와 관련이 있습니다.요청을 처리하기 위한 중앙 집중식 진입 지점을 제공합니다. 아니요. 아니요.

J2EE Patterns[17] PoEAA[18]

마커 메타데이터를 클래스에 연결하기 위한 빈 인터페이스입니다. 아니요. 아니요. 효과적인 자바[19]
모듈 클래스, 싱글톤, 메서드, 글로벌하게 사용되는 여러 관련 요소를 단일 개념 엔티티로 그룹화합니다. 아니요. 아니요. —
프록시 다른 개체에 대한 액세스를 제어할 대리 또는 자리 표시자를 제공합니다. 네. 아니요. —
쌍둥이[20] Twin을 사용하면 이 기능을 지원하지 않는 프로그래밍 언어로 여러 상속을 모델링할 수 있습니다. 아니요. 아니요. —

행동 패턴

이름. 묘사 디자인 패턴 코드[14] 컴플리트 중 다른.
칠판 서로 다른 데이터 소스를 결합하기 위한 인공지능 패턴(칠판 시스템 참조) 아니요. 아니요. —
책임계통 여러 오브젝트에 요청을 처리할 수 있는 기회를 주어 요청의 송신자와 수신자가 결합되지 않도록 합니다.수신 개체를 체인으로 하고 개체가 처리할 때까지 체인을 따라 요청을 전달합니다. 네. 아니요. —
명령어 요구를 오브젝트로 캡슐화함으로써 요구가 다른 클라이언트의 파라미터화 및 요구의 큐잉 또는 로깅을 가능하게 합니다.또한 실행 취소 가능한 작업을 지원할 수 있습니다. 네. 아니요. —
통역사 언어를 지정하면 해당 언어의 문장을 해석하기 위해 해당 표현을 사용하는 통역사와 함께 문법에 대한 표현을 정의합니다. 네. 아니요. —
반복기 기본 표현을 노출하지 않고 Aggregate 객체의 요소에 순차적으로 액세스할 수 있는 방법을 제공합니다. 네. 네. —
중개자 개체 집합이 상호 작용하는 방식을 캡슐화하는 개체를 정의합니다.중개자는 오브젝트가 서로 명시적으로 참조하는 것을 방지함으로써 느슨한 결합을 촉진하고 상호작용을 독립적으로 변화시킵니다. 네. 아니요. —
기념품 캡슐화를 위반하지 않고 개체의 내부 상태를 캡처하고 외부화하면 나중에 개체를 이 상태로 복원할 수 있습니다. 네. 아니요. —
Null 객체 기본 개체를 제공하여 null 참조를 방지하십시오. 아니요. 아니요. —
옵서버 또는 게시/구독 개체 간의 일대다 종속성을 정의합니다. 개체 간의 상태 변경으로 인해 모든 종속 요소에 알림이 자동으로 전송되고 업데이트됩니다. 네. 네. —
하인 클래스 그룹의 공통 기능을 정의합니다.서번트 패턴은 종종 특정 클래스 세트에 대한 도우미 클래스 또는 유틸리티 클래스 구현이라고도 합니다.도우미 클래스에는 일반적으로 객체가 없기 때문에 다른 종류의 클래스 객체에 대해 동작하는 모든 스태틱메서드가 있습니다 아니요. 아니요. —
사양 부울 방식으로 재결합 가능한 비즈니스 로직. 아니요. 아니요. —
주 내부 상태가 변경될 때 개체의 동작을 변경할 수 있습니다.개체가 클래스를 변경하는 것처럼 나타납니다. 네. 아니요. —
전략. 알고리즘 패밀리를 정의하고 각 알고리즘을 캡슐화하여 서로 교환할 수 있도록 합니다.전략을 통해 알고리즘을 사용하는 클라이언트와 독립적으로 변경할 수 있습니다. 네. 네. —
템플릿 방식 연산에서 알고리즘의 골격을 정의하여 일부 단계를 하위 클래스로 지연시킵니다.템플릿 메서드를 사용하면 알고리즘의 구조를 변경하지 않고 하위 클래스가 알고리즘의 특정 단계를 재정의할 수 있습니다. 네. 네. —
방문자 클래스 집합의 인스턴스에서 수행할 작업을 나타냅니다.Visitor를 사용하면 동작하는 요소의 클래스를 변경하지 않고 새로운 동작을 정의할 수 있습니다. 네. 아니요. —
Fluent 인터페이스 메서드 체인이 되는 API를 DSL과 같이 읽도록 설계합니다.각 메서드 호출은 다음 논리 메서드 호출을 사용할 수 있는 컨텍스트를 반환합니다. 아니요. 아니요. —

동시성 패턴

이름. 묘사 POSA2의[21] 경우 다른.
액티브 오브젝트 자체 제어 스레드에 있는 메서드 호출에서 메서드 실행을 분리합니다.목적은 비동기 메서드 호출과 요청을 처리하기 위한 스케줄러를 사용하여 동시성을 도입하는 것입니다. 네. —
망설이다 개체가 특정 상태에 있을 때만 개체에 대한 작업을 실행하십시오. 아니요. —
바인딩 속성 여러 관찰자를 결합하여 여러 개체의 속성을 강제로 동기화하거나 [22]조정할 수 있습니다. 아니요. —
컴퓨팅 커널 GPU에 최적화된 매트릭스 곱셈이나 컨볼루션 뉴럴 네트워크와 같은 공유 어레이에 분기하지 않는 포인터 산술에 사용되는 정수 파라미터에 따라 여러 번 같은 계산이 병렬로 이루어집니다. 아니요. —
이중 확인 잠금 잠금 기준('잠금 힌트')을 안전하지 않은 방법으로 먼저 테스트하여 잠금 획득에 따른 오버헤드를 줄입니다. 이 테스트에 성공한 경우에만 실제 잠금 로직이 진행됩니다.

일부 언어/하드웨어 조합으로 구현될 경우 안전하지 않을 수 있습니다.따라서 안티 패턴으로 간주될 수 있습니다.

네. —
이벤트 기반 비동기 멀티스레드 [23]프로그램에서 발생하는 비동기 패턴 문제를 해결합니다. 아니요. —
가드 서스펜션 작업을 실행하기 전에 잠금과 전제 조건을 모두 충족해야 하는 작업을 관리합니다. 아니요. —
합류하다 Join-pattern은 메시지 전달을 통해 동시, 병렬 및 분산 프로그램을 쓰는 방법을 제공합니다.스레드나 잠금을 사용하는 것과 비교하면 고급 프로그래밍 모델입니다. 아니요. —
잠그다 한 스레드는 리소스에 "잠금"을 설정하여 [24]다른 스레드가 리소스에 액세스하거나 수정할 수 없도록 합니다. 아니요. PoEAA[15]
Messaging Design Pattern(MDP; 메시지 설계 패턴) 컴포넌트와 애플리케이션 간에 정보(메시지 등)를 교환할 수 있습니다. 아니요. —
모니터 객체 메서드가 상호 제외되기 때문에 여러 개체가 동시에 잘못 사용하는 것을 방지합니다. 네. —
리액터 Reactor 객체는 동기적으로 처리해야 하는 리소스에 대한 비동기 인터페이스를 제공합니다. 네. —
읽기/쓰기 잠금 개체에 대한 동시 읽기 액세스를 허용하지만 쓰기 작업에는 독점 액세스 권한이 필요합니다.기본 세마포어를 쓰기에 사용할 수 있으며 Copy-on-Write 메커니즘을 사용할 수도 있습니다. 아니요. —
스케줄러 스레드가 단일 스레드 코드를 실행할 수 있는 시기를 명시적으로 제어합니다. 아니요. —
스레드 풀 많은 태스크를 수행하기 위해 여러 스레드가 생성되며, 일반적으로 이러한 스레드는 대기열로 구성됩니다.일반적으로 스레드보다 더 많은 작업이 있습니다.오브젝트 풀 패턴의 특수한 케이스로 간주할 수 있습니다. 아니요. —
스레드 고유의 스토리지 스레드에 로컬한 정적 메모리 또는 "글로벌" 메모리. 네. —
배타적 소유권과의 안전한 동시성 독점적 소유권을 입증할 수 있기 때문에 런타임 동시 메커니즘이 필요하지 않습니다.이것은 Rust 언어의 주목할 만한 기능이지만 컴파일 타임 체크만이 유일한 수단이 아닙니다.프로그래머는 이러한 패턴을 수동으로 코드로 설계하고, 프로그래머는 주어진 변수가 동시에 액세스 되지 않는다고 판단하기 때문에 잠금 메커니즘을 사용하지 않습니다. 아니요. —
CPU 아토믹 오퍼레이션 x86 및 기타 CPU 아키텍처는 원시 값(정수)을 수정하고 액세스하기 위한 메모리 안전을 보장하는 다양한 원자 명령을 지원합니다.예를 들어, 2개의 스레드 모두 카운터를 안전하게 증가시킬 수 있습니다.이러한 기능은 위와 같은 다른 동시성 패턴의 메커니즘을 구현하기 위해서도 사용할 수 있습니다.C# 언어에서는 이러한 기능에 Interlocked 클래스를 사용합니다. 아니요. —

문서

설계 패턴의 문서에서는 패턴이 사용되는 컨텍스트, 패턴이 해결하려는 컨텍스트 내의 힘 및 제안된 [25]솔루션에 대해 설명합니다.설계 패턴을 문서화하기 위한 단일 표준 형식은 없습니다.오히려 다양한 패턴 작성자가 다양한 형식을 사용해 왔습니다.그러나 Martin Fowler에 따르면, 특정 패턴 형태는 다른 패턴보다 더 잘 알려졌고, 결과적으로 새로운 패턴 작성 [26]노력의 공통적인 출발점이 되었다.일반적으로 사용되는 문서 형식의 한 예는 Erich Gamma, Richard Helm, Ralph Johnson 및 John Vlissides가 책 디자인 패턴에서 사용한 것입니다.이 섹션은 다음과 같습니다.

  • 패턴 이름 및 분류:패턴을 식별하고 참조하는 데 도움이 되는 설명적이고 고유한 이름입니다.
  • 의도: 패턴의 배후에 있는 목표와 그 사용 이유에 대한 설명.
  • 다른 이름: 패턴의 다른 이름.
  • 동기(힘):문제와 이 패턴을 사용할 수 있는 컨텍스트로 구성된 시나리오입니다.
  • 적용 가능성: 이 패턴을 사용할 수 있는 상황. 패턴의 컨텍스트.
  • 구조: 패턴을 그래픽으로 표현합니다.클래스 다이어그램과 인터랙션 다이어그램을 이 목적으로 사용할 수 있습니다.
  • 참가자:패턴에 사용된 클래스 및 객체와 설계에서 해당 역할 목록입니다.
  • 콜라보레이션:패턴에서 사용되는 클래스와 객체가 서로 상호 작용하는 방법에 대한 설명입니다.
  • 결과:패턴을 사용함으로써 발생하는 결과, 부작용 및 트레이드오프에 대한 설명입니다.
  • 구현:패턴 구현에 대한 설명. 패턴의 솔루션 부분.
  • 샘플 코드: 프로그래밍 언어에서 패턴을 사용하는 방법을 보여 줍니다.
  • 알려진 용도: 패턴의 실제 사용 예.
  • 관련 패턴:패턴과 어느 정도 관련이 있는 다른 패턴: 패턴과 유사한 패턴 간의 차이점에 대한 논의.

비판

설계 패턴은 특정 프로그래밍 언어(예를 들어 Java 또는 C++)에서 일부 기능이 누락된 신호일 수 있습니다.Peter Norvig는 Design Patterns 책(주로 C++에 초점을 맞추고 있음)의 23가지 패턴 중 16개가 리스프 또는 [27]딜런에서 단순화 또는 제거되었음을 보여줍니다.관련 관찰은 측면 지향 프로그래밍 언어(AspectJ)를 사용하여 23개의 설계 패턴 중 몇 가지를 구현한 Hannemann과 Kiczales에 의해 이루어졌으며 코드 수준의 의존성이 23개의 설계 패턴 중 17개의 구현에서 제거되었고 측면 지향 프로그래밍이 d의 구현을 단순화할 수 있음을 보여주었다.무늬를 [28]엣지하다Paul Graham의 에세이 "괴짜들의 복수"[29]를 참조하십시오.

패턴을 부적절하게 사용하면 [30]복잡성이 불필요하게 증가할 수 있습니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ Smith, Reid (October 1987). Panel on design methodology. OOPSLA '87 Addendum to the Proceedings. doi:10.1145/62138.62151. Ward cautioned against requiring too much programming at, what he termed, 'the high level of wizards.' He pointed out that a written 'pattern language' can significantly improve the selection and application of abstractions. He proposed a 'radical shift in the burden of design and implementation' basing the new methodology on an adaptation of Christopher Alexander's work in pattern languages and that programming-oriented pattern languages developed at Tektronix has significantly aided their software development efforts.
  2. ^ Beck, Kent; Cunningham, Ward (September 1987). Using Pattern Languages for Object-Oriented Program. OOPSLA '87 workshop on Specification and Design for Object-Oriented Programming. Retrieved 2006-05-26.
  3. ^ Baroni, Aline Lúcia; Guéhéneuc, Yann-Gaël; Albin-Amiot, Hervé (June 2003). "Design Patterns Formalization". Nantes: École Nationale Supérieure des Techniques Industrielles et des Mines de Nantes. CiteSeerX 10.1.1.62.6466. {{cite journal}}:Cite 저널 요구 사항 journal=(도움말)
  4. ^ Bishop, Judith. "C# 3.0 Design Patterns: Use the Power of C# 3.0 to Solve Real-World Problems". C# Books from O'Reilly Media. Retrieved 2012-05-15. If you want to speed up the development of your .NET applications, you're ready for C# design patterns -- elegant, accepted and proven ways to tackle common programming problems.
  5. ^ Tiako, Pierre F. (31 March 2009). "Formal Modeling and Specification of Design Patterns Using RTPA". In Tiako, Pierre F (ed.). Software Applications: Concepts, Methodologies, Tools, and Applications: Concepts, Methodologies, Tools, and Applications. p. 636. doi:10.4018/978-1-60566-060-8. ISBN 9781605660615.
  6. ^ Meyer, Bertrand; Arnout, Karine (July 2006). "Componentization: The Visitor Example" (PDF). IEEE Computer. 39 (7): 23–30. CiteSeerX 10.1.1.62.6082. doi:10.1109/MC.2006.227. S2CID 15328522.
  7. ^ Laakso, Sari A. (2003-09-16). "Collection of User Interface Design Patterns". University of Helsinki, Dept. of Computer Science. Retrieved 2008-01-31.
  8. ^ Heer, J.; Agrawala, M. (2006). "Software Design Patterns for Information Visualization". IEEE Transactions on Visualization and Computer Graphics. 12 (5): 853–60. CiteSeerX 10.1.1.121.4534. doi:10.1109/TVCG.2006.178. PMID 17080809. S2CID 11634997.
  9. ^ Dougherty, Chad; Sayre, Kirk; Seacord, Robert C.; Svoboda, David; Togashi, Kazuya (2009). Secure Design Patterns (PDF). Software Engineering Institute.
  10. ^ Garfinkel, Simson L. (2005). Design Principles and Patterns for Computer Systems That Are Simultaneously Secure and Usable (Ph.D. thesis).
  11. ^ "Yahoo! Design Pattern Library". Archived from the original on 2008-02-29. Retrieved 2008-01-31.
  12. ^ "How to design your Business Model as a Lean Startup?". 2010-01-06. Retrieved 2010-01-06.
  13. ^ 프로그래밍, 회의 절차의 패턴 언어 (연차, 1994-) [1]
  14. ^ a b c McConnell, Steve (June 2004). "Design in Construction". Code Complete (2nd ed.). Microsoft Press. p. 104. ISBN 978-0-7356-1967-8. Table 5.1 Popular Design Patterns
  15. ^ a b Fowler, Martin (2002). Patterns of Enterprise Application Architecture. Addison-Wesley. ISBN 978-0-321-12742-6.
  16. ^ C. Martin, Robert (2002). "28. Extension object". Agile Software Development, Principles, Patterns, and Practices. p. 408. ISBN 978-0135974445.
  17. ^ Alur, Deepak; Crupi, John; Malks, Dan (2003). Core J2EE Patterns: Best Practices and Design Strategies. Prentice Hall. p. 166. ISBN 978-0-13-142246-9.
  18. ^ Fowler, Martin (2002). Patterns of Enterprise Application Architecture. Addison-Wesley. p. 344. ISBN 978-0-321-12742-6.
  19. ^ Bloch, Joshua (2008). "Item 37: Use marker interfaces to define types". Effective Java (Second ed.). Addison-Wesley. p. 179. ISBN 978-0-321-35668-0.
  20. ^ "Twin – A Design Pattern for Modeling Multiple Inheritance" (PDF).
  21. ^ Schmidt, Douglas C.; Stal, Michael; Rohnert, Hans; Buschmann, Frank (2000). Pattern-Oriented Software Architecture, Volume 2: Patterns for Concurrent and Networked Objects. John Wiley & Sons. ISBN 978-0-471-60695-6.
  22. ^ 바인딩 속성
  23. ^ Nagel, Christian; Evjen, Bill; Glynn, Jay; Watson, Karli; Skinner, Morgan (2008). "Event-based Asynchronous Pattern". Professional C# 2008. Wiley. pp. 570–571. ISBN 978-0-470-19137-8.
  24. ^ 잠금 패턴
  25. ^ Gabriel, Dick. "A Pattern Definition". Archived from the original on 2007-02-09. Retrieved 2007-03-06.
  26. ^ Fowler, Martin (2006-08-01). "Writing Software Patterns". Retrieved 2007-03-06.
  27. ^ Norvig, Peter (1998). Design Patterns in Dynamic Languages.
  28. ^ Hannemann, Jan; Kiczales, Gregor (2002). "Design pattern implementation in Java and AspectJ". Proceedings of the 17th ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications - OOPSLA '02. OOPSLA '02. p. 161. doi:10.1145/582419.582436. ISBN 1581134711.{{cite conference}}: CS1 유지보수: 위치(링크)
  29. ^ Graham, Paul (2002). "Revenge of the Nerds". Retrieved 2012-08-11.
  30. ^ McConnell, Steve (2004). Code Complete: A Practical Handbook of Software Construction, 2nd Edition. p. 105.

추가 정보