연관토픽
개념 : 효율적인 객체지향 설계를 위한 경험 모음집
- 프로그래머들이 유용하다고 생각되는 객체들의 일반적인 상호 작용 방법들을 모은 목록으로 여러 번 반복하여 사용할 수 있는 문제에 대한 솔루션을 기술한 것
- 소프트웨어 디자인에서 통속적으로 발생하는 문제에 대한 일반적으로 재사용이 가능한 해결책 혹은 경험적인 솔루션
- 특정 영역의 설계 문제를 해결하기 위해 고안된 형식적인 방법
- 소프트웨어 개발 상에서 나타나는 문제를 해결하기 위한 엔지니어의 경험과 노하우를 재사용하기 용이한 형태로 묶은 모음
- 재사용 가능한 객체지향 설계를 만들기 위해 유용한 공통의 설계 구조로부터 중요 요소들을 식별하여 이들에게 적당한 이름을 주고 추상화한 것
디자인 패턴의 목적
- 설계자로 하여금 재사용을 가능하게 하는 설계를 선택하게 하고 재사용을 방해하는 설계는 배제하도록 함, 즉 ‘올바른’ 설계를 빨리 만들 수 있도록 하는 목적
- 전문가들의 설계 노하우를 다른 개발자가 이해하고 적용할 수 있는 형태로 제공하여 확장성, 재사용성, 유지보수성이 좋은 소프트웨어를 설계하기 위한 목적
디자인 패턴의 특징
| 특징 | 설명 |
| 상속보다는 위임 |
|
| 클래스보다는 인터페이스 |
|
| 커플링 최소화 |
|
| 의사소통 원활 |
|
디자인 패턴의 역사
더보기
1990년대 초반 Gamma에 의해 디자인 패턴에 관한 연구 시작되었고 일반적으로 GoF(Gang of Four)의 분류가 많이 사용되고 있는데 이는 23개의 일반적이고 유용한 패턴들을 제공하고 있음(Gamma 1995)
디자인 패턴 형식(GoF)
| 구분 | 내용 |
| 이름(Name) | - 패턴 자체의 내용을 효과적으로 전달할 수 있는 이름 |
| 종류(Classification) | - 여러 개의 패턴을 체계적으로 분류 - 생성(Creational): 객체들의 생성과 관련 - 구조(Structural): 클래스, 객체의 정적인 구조와 관련 - 행위(Behavioral): 클래스와 객체의 반응과 책임할당 |
| 의도(Intent) | - 이 패턴이 무엇을 하며, 어떤 의도로 작성되었는지 무엇을 해결하는지를 설명하여 기술 |
| 별칭(Also known as) | - 위의 공식적인 이름 외에 잘 알려진 다른 이름 |
| 동기(Motivation) | - 이 패턴이 해결하여야 하는 디자인 문제와 해결하기 위해 클래스와 객체들이 어떻게 사용되는지에 대해 시나리오 형식으로 기술 |
| 구조(Structure) | - 패턴 안에서 문제를 해결하기 위해 사용되는 클래스와 객체의 구조 - UML 다이어그램을 통해 표현 |
| 구성물 | - 구조항목에 포함된 각종 클래스, 객체의 의미와 그 책임을 설명 |
| 협력과정(Collaboration) | - 각 클래스와 객체가 자신에게 맡겨진 책임을 수행하기 위해 서로 메시지를 주고받는 과정을 묘사 |
| 결과(Consequence) | - 패턴이 목적을 달성하기 위해 어떤 면을 해결하는지 설명하고 패턴을 적용할 때 발생할 수 있는 문제점과 패턴 적용 시 효과 - 시스템 상황에 대해 변동하는 부분들을 기술 |
| 샘플코드 | - 특정언어로 패턴을 구현한 예제 - 실제로 사용되는 시스템에서 발견되는 패턴의 예제 |
| 관련 패턴 | 본 패턴과 유사하거나 밀접하게 관련된 다른 패턴 |
디자인 패턴의 원칙
- 구현(Implementation) 클래스가 아니라, 인터페이스(Interface)를 가지고 프로그래밍
- 인터페이스 클래스의 메소드를 바탕으로 호출
- 인터페이스를 구현한 클래스의 내부 변화(비즈니스 로직 변경)에 영향을 받지 않음
- 상속(Inheritance)이 아니라 위임(Delegation)을 사용
- 불필요한 수퍼 클래스의 속성 및 메소드를 상속받음
- 상속의 경우 컴파일시 수퍼클래스와 서브클래스의 구조가 결정됨
- 위임의 경우 런타임 시 필요한 클래스를 사용
- 커플링(Coupling)을 최소화
- God Class를 만들지 않음
- 한 클래스의 변화가 전체 클래스를 변화되지 않게 해야 함
디자인 패턴의 유형
| 분류기준 | 유형 | 설명 |
| 목적 | 생성 | - 객체 인스턴스 생성에 관여, 클래스 정의와 객체 생성 방식을 구조화, 캡슐화를 수행하는 패턴 |
| 구조 | - 더 큰 구조 형성 목적으로 클래스나 객체의 조합을 다루는 패턴 | |
| 행위 | - 클래스나 객체들이 상호작용하는 방법과 역할 분담을 다루는 패턴 | |
| 범위 | 클래스 | - 클래스 간 관련성 즉, 상속관계를 다루는 패턴 - 컴파일 타임(Compile Time)에 정적으로 결정 |
| 객체 | - 객체 간 관련성을 다루는 패턴 - 런 타임(Run Time)에 동적으로 결정 |
디자인 패턴 분류(Gamma)
| 구분 | 생성패턴 | 구조패턴 | 행위패턴 | |
| 의미 | 객체의 생성방식 결정 패턴 | 객체를 조직화하는 일반적인 방식 제시 | 객체의 행위를 조직화, 관리, 연합하고 객체나 클래스 연동에 대한 유형 제시 | |
| 범위 | 클래스 | Factory method | Adaptor(Class) | Interpreter/Template method |
| 객체 | Abstract Factory: 제품객체군 Builder: 복합 객체 생성 Prototype: 인스턴스화 될 객체 클래스 Singleton: 인스턴스가 하나일 때 |
Adaptor Bridge: 객체 구현 Composite: 객체의 합성과 구조 Decorator: 서브클래싱 없이 객체의 책임성 Façade: 서브시스템에 대한 인터페이스 Flyweight: 객체 저장 비용 Proxy: 객체 접근방법 |
Chain of Responsibility: 요청처리객체 Command: 요청 처리 시점과 방법 Iterator: 집합객체 요소 접근/순회방법 Mediator: 객체 상호 작용 Memento: 객체정보 외부 저장 Observer: 종속객체 상태 변경 State: 객체 상태 Strategy: 알고리즘 Visitor: 클래스 변경 없이 객체에 적용할 수 있는 오퍼레이션 |
|
디자인 패턴 분류
더보기
1) 객체 생성 패턴
- 객체의 인스턴스 생성을 위한 패턴으로, 클라이언트와 그 클라이언트에서 생성해야 할 객체 인스턴스 사이의 연결을 끊어주는 패턴. 클래스 정의와 객체 생성 방식을 구조화, 캡슐화한 방법을 제시
2) 구조 개선 패턴
- 다른 기능을 가진 객체가 협력을 통해 어떤 역할을 수행할 때, 객체를 조직화시키는 일반적인 방식을 제시하여 별도로 구성된 클래스 라이브러리를 통합하는 데 유용
- 생성패턴과 달리 새로운 기능을 구현하기 위해 객체를 구성하는 방식 자체에 초점 맞춤
3) 행위 개선 패턴
- 객체의 행위를 조직화, 관리, 연합하는데 사용되는 패턴으로 객체간의 기능을 배분하는 일과 같은 알고리즘 수행에 주로 이용
- 단지 객체나 클래스에 대한 유형을 정의하는 것이 아니라 그들 간의 연동에 대한 유형을 제시
유용한 패턴
| 분류 | 패턴명 | 설명 |
| 생성 | Abstract Factory | 구체적인 클래스를 지정하지 않고 관련성을 갖는 객체들의 집합을 생성하거나 서로 독립적인 객체들의 집합을 생성할 수 있는 인터페이스를 제공하는 패턴 |
| Builder | 복합 객체의 생성 과정과 표현 방법을 분리하여 동일한 생성 절차에서 서로 다른 표현 결과를 만들 수 있게 하는 패턴 | |
| Factory Method | 객체를 생성하는 인터페이스는 미리 정의하되, 인스턴스를 만들 클래스의 결정은 서브클래스 쪽에서 내리는 패턴. 클래스의 인스턴스를 만드는 시점을 서브클래스로 미룸 | |
| Prototype | 생성할 객체의 종류를 명세하는 데에 원형이 되는 예시물을 이용하고, 그 원형을 복사함으로써 새로운 객체를 생성하는 패턴 | |
| Singleton | 어떤 클래스의 인스턴스는 오직 하나임을 보장하며, 이 인스턴스에 접근할 수 있는 전역적인 접촉점을 제공하는 패턴 | |
| 구조 | Adapter | 클래스의 인터페이스를 사용자가 기대하는 다른 인터페이스로 변환하는 패턴으로, 호환성이 없는 인터페이스 때문에 함께 동작할 수 없는 클래스들이 함께 작동하도록 해줌 |
| Bridge | 구현부에서 추상층을 분리하여 각자 독립적으로 변형할 수 있는 패턴 | |
| Composite | 객체들의 관계를 트리 구조로 구성하여 부분-전체 계층을 표현하는 패턴. 사용자가 단일 객체와 복합 객체 모두 동일하게 다루도록 함 | |
| Decorator | 주어진 상황 및 용도에 따라 어떤 객체에 책임을 덧붙이는 패턴으로, 기능 확장이 필요할 때 서브클래싱 대신 쓸 수 있는 유연한 대안이 될 수 있음 | |
| Façade | 서브시스템에 있는 인터페이스 집합에 대해서 하나의 통합된 인터페이스를 제공하는 패턴으로, 서브시스템을 좀 더 사용하기 편하게 만드는 상위 수준의 인터페이스를 정의 | |
| Flyweight | 크기가 작은 객체가 여러 개 있을 때, 공유를 통해 이들을 효율적으로 지원하는 패턴 | |
| Proxy | 어떤 다른 객체로 접근하는 것을 통제하기 위해서 그 객체의 대리자 또는 자리채움자를 제공하는 패턴 | |
| 행동 | Chain of Responsibility |
요청을 처리할 수 있는 기회를 하나 이상의 객체에 부여하여 요청을 보내는 객체와 그 요청을 받는 객체 사이의 결합을 피하는 패턴. 요청을 받을 수 있는 객체를 연쇄적으로 묶고, 실제 요청을 처리할 객체를 만날 때까지 객체 고리를 따라서 요청을 전달 |
| Command | 요청을 객체의 형태로 캡슐화하여 서로 요청이 다른 사용자의 매개변수화, 요청 저장 또는 로깅, 그리고 연산의 취소를 지원하게 만드는 패턴 | |
| Interpreter | 주어진 언어에 대해, 그 언어의 문법을 위한 표현 수단을 정의하고, 이와 아울러 그 표현 수단을 사용하여 해당 언어로 작성된 문장을 해석하는 해석기를 정의하는 패턴 | |
| Iterator | 내부 표현부를 노출하지 않고 어떤 객체 집합에 속한 원소들을 순차적으로 접근할 수 있는 방법을 제공하는 패턴 | |
| Mediator | 한 집합에 속해 있는 객체들의 상호작용을 캡슐화하는 객체를 정의하는 패턴. 객체들이 직접 서로를 참조하지 않도록 함으로써 객체들 사이의 소결합을 촉진시키며, 개발자가 객체들의 상호작용을 독립적으로 다양화시킬 수 있게 만듦 | |
| Memento | 캡슐화를 위배하지 않은 채로 어떤 객체의 내부 상태를 잡아내고 실체화시켜, 이후에 해당 객체가 그 상태로 되돌아올 수 있는 패턴 | |
| Observer | 객체들 사이에 일 대 다의 의존 관계를 정의해 두어, 어떤 객체의 상태가 변할 때 그 객체에 의존성을 가진 다른 객체들이 그 변화를 통지받고 자동으로 갱신될 수 있게 만드는 패턴 | |
| State | 객체의 내부 상태에 따라 스스로 행동을 변경할 수 있게끔 허가하는 패턴으로, 이렇게 하면 객체는 마치 자신의 클래스를 바꾸는 것처럼 보임 | |
| Strategy | 동일 계열의 알고리즘군을 정의하고, 각각의 알고리즘을 캡슐화하며, 이들을 상호 교환이 가능하도록 만드는 패턴. 알고리즘을 사용하는 사용자와 상관없이 독립적으로 알고리즘을 다양하게 변경할 수 있게 함 | |
| Template method |
객체의 연산에는 알고리즘의 뼈대만을 정의하고 각 단계에서 수행할 구체적 처리는 서브클래스 쪽으로 미루는 패턴. 알고리즘 구조 자체는 그대로 놔둔 채 알고리즘의 각 단계의 처리를 서브클래스에서 재정의 | |
| Visitor | 객체 구조를 이루는 원소에 대해 수행할 연산을 표현하는 패턴으로, 연산을 적용할 원소의 클래스를 변경하지 않고도 새로운 연산 정의 가능 |
디자인 패턴과 아키텍처 스타일의 비교
| 구분 | 디자인패턴 | 아키텍처 스타일 |
| 정의 |
|
|
| 관점 |
|
|
| 특징 |
|
|
| 대표적 종류 |
|
|
모범답안
Reference
- 디자인패턴(정리) [file]