1. 디자인 패턴
디자인 패턴은 소프트웨어 설계에서 얻은 경험들을 체계적으로 만들어 특정한 전후 관계에서 일반적 설계 문제를 해결하기 위한 객체 및 클래스에 대한 설명으로 확장과 수정에 용이하게 구축하기 위한 설계 디자인 방법론입니다. 이는 코드 자체의 품질 향상만이 아닌 구조화된 패턴에 대한 사전지식으로 개발자 간의 커뮤니케이션을 수월하도록 만듭니다. 또한 검증되어 있는 구조이기에 안전하게 설계 과정의 속도 높일 수 있습니다.이런 지침 방향을 5가지로 나타낸 것을 SOLID 원칙이라고 합니다.
2. SOLID 원칙 (객체지향 5대 원칙)
[SRP (Single Responsiblity Principle, 단일 책임 원칙)]
클래스나 함수는 단 하나의 책임만을 가져야 한다.
설계를 잘한 프로그램은 기본적으로 새로운 요구사항과 프로그램 변경에 영향을 받는 부분이 적습니다. 다시말해, 응집도는 높고 결합도는 낮은 프로그램을 뜻한다. 만약 한 클래스가 수행해야하는 기능이 많아져 비대해진다면 분산을 시킬 필요성이 생깁니다. 기능이 많아지면 클래스 내부의 함수끼리 강한 결합을 발생할 가능성이 높아지고 이는 유지보수에 비용이 증가하게 되므로 따라서 책임을 분리시킬 필요가 있다.
[OCP (Open-Closed Principle, 개방-폐쇄 원칙)]
확장에는 여려있고, 기존 코드 변경에는 닫혀있도록 설계해야 한다.
OCP에 만족하는 설계를 할 때 변경되는 것이 무엇인지에 초점을 맞춥니다. 자주 변경될 수 있는 내용은 수정하기 쉽게, 변경되지 않아야 하는 것은 수정에 영향을 받지 않아야 합니다. 이를 위해 자주 interface를 활용합니다.
[LSP (Liskov Substitution Principle, 리스코프 치환 원칙)]
자식 클래스는 부모 클래스에서 가능한 행위를 수행할 수 있어야 한다.
리스코프 치환 원칙은 MIT 컴퓨터 사이언스 교수인 리스코프가 제안한 설계 원칙로, 부모 클래스와 자식 클래스 사이의 행위에는 일관성이 있어야 한다는 원칙이며, 즉 올바른 상속 관계의 여부를 확인해야 합니다. 이는 객체 지향 프로그래밍에서 부모 클래스를 대신하여 자식 클래스가 사용되도 문제가 없는 일반화 관계(IS-A)가 성립해야 한다.
[ISP (Interface Segregation Principle, 인터페이스 분리 원칙)]
한 클래스는 자신이 사용하지 않는 인터페이스는 구현하지 않아야 하며, 하나의 인터페이스보다는 여러 개의 구체적인 인터페이스가 낫다.
이는 다시 말해, 클라이언트는 자신이 사용하지 않는 메서드에는 의존하지 않아야 한다는 뜻입니다. 큰 덩어리의 인터페이스를 기능에 따라 작은 단위로 분산시켜 필요한 메서드만 사용할 수 있도록 합니다. 예시로 스마트 폰으로는 다양한 기능이 수행 가능하지만, 우리는 한 인터페이스에서 모든 것을 수행하지 않고 기능에 따라 독립적으로 구현된 인터페이스를 사용합니다. 이렇게 설계된 소프트웨어는 인터페이스 분리 원칙을 통해 시스템의 내부 의존성을 약화시켜 리팩토링, 수정, 재배포를 쉽게 할 수 있습니다.
[DIP (Dependency Inversion Principle, 의존 역전원칙)]
의존 관계를 맺을 때, 변화하기 쉬운 것보단 변화하기 어려운 것에 의존해야 한다.
여기서 말하는 변화하기 쉬운것이란 구체적인 것(클래스)을 말하고, 변화하기 어려운 것이란 추상적인 것(추상 클래스, 인터페이스)을 얘기합니다. 따라서 DIP를 만족한다는 것은 의존관계를 맺을 때, 구체적인 클래스보다 인터페이스나 추상 클래스와 관계를 맺는다는 것을 의미한다
3. 디자인 패턴 구조
일반적으로 디자인 패턴 구조는 다음의 4개의 필수적인 요소로 구성됩니다.
[패턴 이름(pattern name)]
한 두 단어로 설계 문제와 해법을 서술하여 높은 수준의 추상화된 설계를 할 수 있도록 돕습니다. 의도 및 소통을 표출하여 의사소통의 원할함을 제공합니다.
[문제(problem)]
패턴의 적용 시기와 해당 문제 및 배경을 제시합니다.
[해결(solution)]
문제를 해결하도록 설계를 구성하는 요소들과 그 요소들 사이의 관계, 책임, 협력 관계를 기술합니다. 해법은 구체적이기 보다는 문제에 대한 추상적인 설명 및 해결 위한 클래스 및 객체의 나열 방법을 제공합니다.
[결과(consequence)]
디자인 패턴을 통해 얻는 결과 와 그에 대한 장단점을 서술합니다. 이때 평가 기준을 잘 잡는 것이 중요합니다.
4. GoF (Gang of Four) 디자인 패턴
Gof 디자인 패턴은 에리히 감마, 리차드 헬름, 랄프 존슨, 존 블리시디스가 소프트웨어 개발 영역에서 디자인 패턴을 구체화하고 체계화한 GoF라 불리는 사람들의 이름입니다. GoF에서는 23가지 디자인 패턴을 3가지 유형으로 분류합니다.
[생성 패턴(Creational Pattern)]
객체 생성에 관련된 패턴으로, 객체의 생성과 조합을 캡슐화해 객체 생성 과정의 유연성을 높여 이후 변경되어도 프로그램 구조에 영향을 크게 받지 않아 코드의 유지력을 높입니다.
[구조 패턴(Sturctural Pattern)]
클래스나 객체를 조합해 더 큰 프로그램 구조를 만드는 패턴입니다. 프로그램 내의 자료구조나 인터페이스 구조 등 프로그램의 구조를 설계하는데 사용될 수 있습니다.
[행위 패턴(Behavioral Pattern)]
객체나 클래스 사이의 알고리즘이나 책임 분배에 관련된 패턴으로 반복적으로 사용되는 객체의 상호작용을 패턴화하여 객체사이의 결합도를 최소화하는 것에 중점을 두고 있습니다.
5. UML 표기법
디자인 패턴의 설계는 기본적으로 UML 로 표기 되기에 이에 대한 이해가 필요합니다. 디자인 패턴에서는 UML 중에서도 클래스 다이어그램을 중심으로 이용합니다.
Java 객체지향 디자인 패턴] 1. 객체지향 모델링 / UML, 클래스 다이어그램, 연관 관계, 일반화 관계,
Java 객체지향 디자인 패턴] 1. 객체지향 모델링 / UML, 클래스 다이어그램, 연관 관계, 일반화 관계, ...
blog.naver.com
위의 블로그를 참조하면 좋습니다.
'C++공부 > GoF의 디자인 패턴' 카테고리의 다른 글
| 단일체(Singleton) (0) | 2022.05.18 |
|---|---|
| 원형(Prototype) (0) | 2022.05.18 |
| 팩토리 메서드(Factory Method) (0) | 2022.05.18 |
| 빌더(Builder) (0) | 2022.05.18 |
| 추상 팩토리(Abstract Factory) (0) | 2022.05.18 |