GoF 디자인 패턴: Difference between revisions
From CS Wiki
(새 문서: '''Gang of Four Design Pattern''' 4명의 컴퓨터 공학자<ref>에리히 감마(Erich Gamma), 리처드 헬름(Richard Helm), 랄프 존슨(Ralph Johnson), 존 블리시데스(Joh...) |
|||
(5 intermediate revisions by 3 users not shown) | |||
Line 3: | Line 3: | ||
4명의 컴퓨터 공학자<ref>에리히 감마(Erich Gamma), 리처드 헬름(Richard Helm), 랄프 존슨(Ralph Johnson), 존 블리시데스(John Vlissides)</ref>에 의해 3개 분류 23가지로 정리된 [[소프트웨어 디자인 패턴]] | 4명의 컴퓨터 공학자<ref>에리히 감마(Erich Gamma), 리처드 헬름(Richard Helm), 랄프 존슨(Ralph Johnson), 존 블리시데스(John Vlissides)</ref>에 의해 3개 분류 23가지로 정리된 [[소프트웨어 디자인 패턴]] | ||
== 구분 == | ==구분== | ||
==== 생성(Creational Pattern) ==== | ====생성 패턴(Creational Pattern)==== | ||
* 객체를 생성하는데 관련된 패턴들 | *객체를 생성하는데 관련된 패턴들 | ||
* 객체가 생성되는 과정의 유연성을 높이고 코드의 유지를 쉽게 함 | *객체가 생성되는 과정의 유연성을 높이고 코드의 유지를 쉽게 함 | ||
==== 구조(Structural Pattern) ==== | ====구조 패턴(Structural Pattern)==== | ||
* 프로그램 구조에 관련된 패턴들 | *프로그램 구조에 관련된 패턴들 | ||
* 프로그램 내의 자료구조나 인터페이스 구조 등 프로그램의 구조를 설계하는데 활용할 수 있는 패턴들 | *프로그램 내의 자료구조나 인터페이스 구조 등 프로그램의 구조를 설계하는데 활용할 수 있는 패턴들 | ||
==== 행위(Behavioral Pattern) ==== | ====행위 패턴(Behavioral Pattern)==== | ||
* 반복적으로 사용되는 객체들의 상호작용을 패턴화 해놓은 것들 | *반복적으로 사용되는 객체들의 상호작용을 패턴화 해놓은 것들 | ||
== 23개 디자인 패턴 == | ==23개 디자인 패턴== | ||
{| class="wikitable" | {| class="wikitable" | ||
! colspan="2" rowspan="2" |디자인패턴 | ! colspan="2" rowspan="2" |디자인패턴 | ||
Line 33: | Line 33: | ||
!클래스 | !클래스 | ||
| | | | ||
* Factory Method | *Factory Method | ||
| | | | ||
* Adaptor | *Adaptor | ||
| | | | ||
* Interpreter | *Interpreter | ||
* Template Method | *Template Method | ||
|- | |- | ||
!객체 | !객체 | ||
| | | | ||
* Abstract Factory | *Abstract Factory | ||
* Builder | *Builder | ||
* Prototype | *Prototype | ||
* Singleton | *Singleton | ||
| | | | ||
* Adaptor | *Adaptor | ||
* Bridge | *Bridge | ||
* Composite | *Composite | ||
* Decorator | *Decorator | ||
* Façade | *Façade | ||
* Flyweight | *Flyweight | ||
* Proxy | *Proxy | ||
| | | | ||
* Chain of Responsibility | *Chain of Responsibility | ||
* Command | *Command | ||
* Iterator | *Iterator | ||
* Mediator | *Mediator | ||
* Memento | *Memento | ||
* Observer | *Observer | ||
* State | *State | ||
* Strategy | *Strategy | ||
* Visitor | *Visitor | ||
|} | |} | ||
===생성 패턴(Creational Pattern)=== | |||
== 디자인 패턴 | ====팩토리 메소드(Factory Method)==== | ||
* Virtual-Constructor 패턴이라고도 함 | |||
*객체를 생성하기 위한 인터페이스를 정의 하여 어떤 클래스가 인스턴스화 될 것인지는 서브클래스가 결정 | |||
*객체 생성을 처리하 인터페이스를 제공하고, 실제 객체 생성은 서브 클래스가 결정하도록 위임 | |||
====추상 팩토리(Abstract Factory)==== | |||
*구체적인 클래스에 의존하지 않고, 서로 연관·의존하는 객체들의 그룹으로 생성하여 추상적으로 표현 | |||
*연관된 서브 클래스를 묶어 한 번에 교체 가능 | |||
====빌더(Builder)==== | |||
*건축가가 블록을 조립하는 모습 | |||
*복잡한 객체의 생성 과정을 여러 단계로 나누어 처리한다. | |||
*분리된 인스턴스(객체)를 건축하듯이 조합하여 객체를 생성 | |||
*동일한 객체 생성에서도 다른 결과 나올 수 있음 | |||
====프로토타입(Prototype)==== | |||
*원본 객체를 복제하는 방법으로 객체를 생성하는 패턴 | |||
*비용이 큰 경우 주로 이용 | |||
====싱글톤(Singleton)==== | |||
*객체를 어디서든 참조할 수 있지만, 여러 프로세스가 동시에 참조하는 것은 불가능 | |||
*인스턴스가 하나뿐이기 때문에 불필요한 메모리 낭비를 최소화 할 수 있음 | |||
*객체의 인스턴스가 오직 하나만 생성되도록 보장한다. | |||
*전역적으로 접근 가능한 단일 인스턴스 제공 | |||
===구조 패턴(Structural Pattern)=== | |||
====어댑터(Adaptor)==== | |||
*호환성을 맞춰주는 변압기 | |||
*클래스들의 호환성이 맞도록 변환해주는 패턴 | |||
*기존의 클래스를 이용하고 싶은데 인터페이스가 일치하지 않을 때 사용 | |||
*호환되지 않는 인터페이스를 가진 클래스들이 함께 작동할 수 있도록 한다. | |||
====브리지(Bridge)==== | |||
*두 섬을 연결하는 다리 | |||
*서로가 독립적으로 확장할 수 있도록 구성한 패턴 | |||
*기능과 구현을 별도의 클래스에서 구현 | |||
*추상화와 구현을 분리하여 두 계층이 독립적으로 변화할 수 있게 한 | |||
====컴포지트(Composite)==== | |||
*폴더와 파일을 합성한 것 | |||
*복합 객체와 단일 객체를 구분 없이 다루고자 할 때 사용 | |||
*복합 객체 안에 복합 객체가 포함되는 구조 구현 가능 | |||
*객체를 트리 구조로 구 | |||
====데코레이터(Decorator)==== | |||
*온갖 것으로 장식된 눈사람 | |||
*객체 간의 결합으로 기능을 확장할 수 있음 | |||
*부가적인 기능 추가를 위해 다른 객체들을 덧붙이는 방식 | |||
*객체에 동적으로 기능을 추가 | |||
====퍼싸드(Facade)==== | |||
*리모컨만으로 복잡한 명령을 수행하는 것 | |||
*상위에 인터페이스를 구성하여 서브 클래스들의 기능을 수행할 수 있음 | |||
*서브 클래스들 사이의 통합 인터페이스를 제공하는 Wrapper 객체 필요 | |||
*복잡한 시스템을 단순화한 디자인 패턴 | |||
*서브 시스템의 제일 앞 쪽에 위치하며, 서브 시스템에 있는 객체들을 사용할 수 있도록 인터페이스 역할을 한다 | |||
====플라이웨이트(Flyweight)==== | |||
*부담을 가볍게 하기 위해 물품 공유 | |||
*인스턴스를 가능한 한 공유해서 사용하여 메모리를 절약 | |||
*다수의 유사 객체를 생성하거나 조작할 때 유용함 | |||
*객체를 공유함으로써 메모리를 절약하는 디자인 패턴 | |||
*객체 생성이 오래 걸리거나, 객체가 많이 생성될 가능성이 있을때 사용 | |||
====프록시(Proxy)==== | |||
*하기 어려운 업무를 대리로 해주는 사람 | |||
*다른 객체에 접근을 제어하거나, 중개하는 디자인 패턴 | |||
*접근이 어려운 객체와 여기 접근하려는 객체 사이의 인터페이스 역할 | |||
*네트워크 연결, 메모리의 대용량 객체로의 접근에 이용 | |||
===행위 패턴(Behavioral Pattern)=== | |||
====책임 연쇄(Chain of Responsibility)==== | |||
*연속해서 나눠받는 물레방아 | |||
*한 객체가 처리하지 못하면 다음 객체로 넘어가는 패턴 | |||
*요청이 해결될 때까지 고리를 따라 책임이 넘어감 | |||
====커맨드(Command)==== | |||
*명령어를 하나로 합쳐둔 것 | |||
*요청을 캡슐화하여 재이용하거나 취소할 수 있도록 저장하거나 로그로 남김 | |||
*추상클래스와 구체클래스로 나뉨 | |||
====인터프리터(Interpreter)==== | |||
*언어 번역가 | |||
*언어에 문법 표현을 정의함 | |||
*SQL이나 통신 프로토콜에 사용 | |||
====반복자(Iterator)==== | |||
*같은 명령의 반복 | |||
*접근이 잦은 객체에 대해 동일한 인터페이스를 사용하도록 함 | |||
*내부 표현 방법의 노출 없이 순차적인 접근 가능 | |||
====중재자(Mediator)==== | |||
*매매를 중개해주는 중개사이트 | |||
*객체들 간의 복잡한 상호작용을 캡슐화하여 객체로 정의 | |||
*객체 사이의 결합도를 감소시킴 | |||
====메멘토(Memento)==== | |||
*기억 속의 그 때로 돌아감. | |||
*객체를 특정 시점의 상태로 돌릴 수 있는 기능 | |||
*ctrl+z 와 같은 기능 개발시 사용 | |||
====옵서버(Observer)==== | |||
*변화를 지켜보고 알려주는 것 | |||
*한 객체의 상태 변화시 상속되어 있는 다른 객체들에게 알림 | |||
*시스템간에 이벤트를 생성하고 수신할 때 사용 | |||
====상태(State)==== | |||
*상태에 따라 다른 방법을 사용함 | |||
*객체의 상태에 따라 동일한 동작을 다르게 처리해야 할 때 사용 | |||
*객체 상태를 캡슐화하고 이를 참조함 | |||
====전략(Strategy)==== | |||
*여러 전략을 정하고 필요할 때 선택하여 씀 | |||
*동일한 계열의 알고리즘을 캡슐화하여 상호 교환할 수 있게 정의함 | |||
*원하는 알고리즘을 선택하여 사용하며 클라이언트에 영향 없이 알고리즘 변경 가능 | |||
====템플릿 메소드(Template Method)==== | |||
*방법들을 큰 틀로 묶는 것 | |||
*상위 클래스에서 골격 정의, 하위 클래스에서 세부 처리를 구체화 | |||
*유사한 서브 클래스의 공통된 내용을 상위 클래스에서 정의(유지보수를 용이하게 함) | |||
====방문자(Visitor)==== | |||
*책을 만들기 위해 저자, 편집자를 번갈아가며 방문 | |||
*각 클래스들의 데이터 구조에서 처리 기능을 별도의 클래스로 구성 | |||
*분리된 기능은 각 클래스를 방문하여 수행 | |||
== ㏂각주 == | |||
<references /> |
Latest revision as of 04:02, 5 October 2024
Gang of Four Design Pattern
4명의 컴퓨터 공학자[1]에 의해 3개 분류 23가지로 정리된 소프트웨어 디자인 패턴
구분[edit | edit source]
생성 패턴(Creational Pattern)[edit | edit source]
- 객체를 생성하는데 관련된 패턴들
- 객체가 생성되는 과정의 유연성을 높이고 코드의 유지를 쉽게 함
구조 패턴(Structural Pattern)[edit | edit source]
- 프로그램 구조에 관련된 패턴들
- 프로그램 내의 자료구조나 인터페이스 구조 등 프로그램의 구조를 설계하는데 활용할 수 있는 패턴들
행위 패턴(Behavioral Pattern)[edit | edit source]
- 반복적으로 사용되는 객체들의 상호작용을 패턴화 해놓은 것들
23개 디자인 패턴[edit | edit source]
디자인패턴
영역 |
목적 | |||
---|---|---|---|---|
생성 | 구조 | 행위 | ||
범위 | 클래스 |
|
|
|
객체 |
|
|
|
생성 패턴(Creational Pattern)[edit | edit source]
팩토리 메소드(Factory Method)[edit | edit source]
- Virtual-Constructor 패턴이라고도 함
- 객체를 생성하기 위한 인터페이스를 정의 하여 어떤 클래스가 인스턴스화 될 것인지는 서브클래스가 결정
- 객체 생성을 처리하 인터페이스를 제공하고, 실제 객체 생성은 서브 클래스가 결정하도록 위임
추상 팩토리(Abstract Factory)[edit | edit source]
- 구체적인 클래스에 의존하지 않고, 서로 연관·의존하는 객체들의 그룹으로 생성하여 추상적으로 표현
- 연관된 서브 클래스를 묶어 한 번에 교체 가능
빌더(Builder)[edit | edit source]
- 건축가가 블록을 조립하는 모습
- 복잡한 객체의 생성 과정을 여러 단계로 나누어 처리한다.
- 분리된 인스턴스(객체)를 건축하듯이 조합하여 객체를 생성
- 동일한 객체 생성에서도 다른 결과 나올 수 있음
프로토타입(Prototype)[edit | edit source]
- 원본 객체를 복제하는 방법으로 객체를 생성하는 패턴
- 비용이 큰 경우 주로 이용
싱글톤(Singleton)[edit | edit source]
- 객체를 어디서든 참조할 수 있지만, 여러 프로세스가 동시에 참조하는 것은 불가능
- 인스턴스가 하나뿐이기 때문에 불필요한 메모리 낭비를 최소화 할 수 있음
- 객체의 인스턴스가 오직 하나만 생성되도록 보장한다.
- 전역적으로 접근 가능한 단일 인스턴스 제공
구조 패턴(Structural Pattern)[edit | edit source]
어댑터(Adaptor)[edit | edit source]
- 호환성을 맞춰주는 변압기
- 클래스들의 호환성이 맞도록 변환해주는 패턴
- 기존의 클래스를 이용하고 싶은데 인터페이스가 일치하지 않을 때 사용
- 호환되지 않는 인터페이스를 가진 클래스들이 함께 작동할 수 있도록 한다.
브리지(Bridge)[edit | edit source]
- 두 섬을 연결하는 다리
- 서로가 독립적으로 확장할 수 있도록 구성한 패턴
- 기능과 구현을 별도의 클래스에서 구현
- 추상화와 구현을 분리하여 두 계층이 독립적으로 변화할 수 있게 한
컴포지트(Composite)[edit | edit source]
- 폴더와 파일을 합성한 것
- 복합 객체와 단일 객체를 구분 없이 다루고자 할 때 사용
- 복합 객체 안에 복합 객체가 포함되는 구조 구현 가능
- 객체를 트리 구조로 구
데코레이터(Decorator)[edit | edit source]
- 온갖 것으로 장식된 눈사람
- 객체 간의 결합으로 기능을 확장할 수 있음
- 부가적인 기능 추가를 위해 다른 객체들을 덧붙이는 방식
- 객체에 동적으로 기능을 추가
퍼싸드(Facade)[edit | edit source]
- 리모컨만으로 복잡한 명령을 수행하는 것
- 상위에 인터페이스를 구성하여 서브 클래스들의 기능을 수행할 수 있음
- 서브 클래스들 사이의 통합 인터페이스를 제공하는 Wrapper 객체 필요
- 복잡한 시스템을 단순화한 디자인 패턴
- 서브 시스템의 제일 앞 쪽에 위치하며, 서브 시스템에 있는 객체들을 사용할 수 있도록 인터페이스 역할을 한다
플라이웨이트(Flyweight)[edit | edit source]
- 부담을 가볍게 하기 위해 물품 공유
- 인스턴스를 가능한 한 공유해서 사용하여 메모리를 절약
- 다수의 유사 객체를 생성하거나 조작할 때 유용함
- 객체를 공유함으로써 메모리를 절약하는 디자인 패턴
- 객체 생성이 오래 걸리거나, 객체가 많이 생성될 가능성이 있을때 사용
프록시(Proxy)[edit | edit source]
- 하기 어려운 업무를 대리로 해주는 사람
- 다른 객체에 접근을 제어하거나, 중개하는 디자인 패턴
- 접근이 어려운 객체와 여기 접근하려는 객체 사이의 인터페이스 역할
- 네트워크 연결, 메모리의 대용량 객체로의 접근에 이용
행위 패턴(Behavioral Pattern)[edit | edit source]
책임 연쇄(Chain of Responsibility)[edit | edit source]
- 연속해서 나눠받는 물레방아
- 한 객체가 처리하지 못하면 다음 객체로 넘어가는 패턴
- 요청이 해결될 때까지 고리를 따라 책임이 넘어감
커맨드(Command)[edit | edit source]
- 명령어를 하나로 합쳐둔 것
- 요청을 캡슐화하여 재이용하거나 취소할 수 있도록 저장하거나 로그로 남김
- 추상클래스와 구체클래스로 나뉨
인터프리터(Interpreter)[edit | edit source]
- 언어 번역가
- 언어에 문법 표현을 정의함
- SQL이나 통신 프로토콜에 사용
반복자(Iterator)[edit | edit source]
- 같은 명령의 반복
- 접근이 잦은 객체에 대해 동일한 인터페이스를 사용하도록 함
- 내부 표현 방법의 노출 없이 순차적인 접근 가능
중재자(Mediator)[edit | edit source]
- 매매를 중개해주는 중개사이트
- 객체들 간의 복잡한 상호작용을 캡슐화하여 객체로 정의
- 객체 사이의 결합도를 감소시킴
메멘토(Memento)[edit | edit source]
- 기억 속의 그 때로 돌아감.
- 객체를 특정 시점의 상태로 돌릴 수 있는 기능
- ctrl+z 와 같은 기능 개발시 사용
옵서버(Observer)[edit | edit source]
- 변화를 지켜보고 알려주는 것
- 한 객체의 상태 변화시 상속되어 있는 다른 객체들에게 알림
- 시스템간에 이벤트를 생성하고 수신할 때 사용
상태(State)[edit | edit source]
- 상태에 따라 다른 방법을 사용함
- 객체의 상태에 따라 동일한 동작을 다르게 처리해야 할 때 사용
- 객체 상태를 캡슐화하고 이를 참조함
전략(Strategy)[edit | edit source]
- 여러 전략을 정하고 필요할 때 선택하여 씀
- 동일한 계열의 알고리즘을 캡슐화하여 상호 교환할 수 있게 정의함
- 원하는 알고리즘을 선택하여 사용하며 클라이언트에 영향 없이 알고리즘 변경 가능
템플릿 메소드(Template Method)[edit | edit source]
- 방법들을 큰 틀로 묶는 것
- 상위 클래스에서 골격 정의, 하위 클래스에서 세부 처리를 구체화
- 유사한 서브 클래스의 공통된 내용을 상위 클래스에서 정의(유지보수를 용이하게 함)
방문자(Visitor)[edit | edit source]
- 책을 만들기 위해 저자, 편집자를 번갈아가며 방문
- 각 클래스들의 데이터 구조에서 처리 기능을 별도의 클래스로 구성
- 분리된 기능은 각 클래스를 방문하여 수행
㏂각주[edit | edit source]
- ↑ 에리히 감마(Erich Gamma), 리처드 헬름(Richard Helm), 랄프 존슨(Ralph Johnson), 존 블리시데스(John Vlissides)