☁ 한창 정보처리기사를 준비할 때 공부했던 내용에 정보를 더 추가해서 알차게 정리해 보았다!
Don't reinvent the wheel.
바퀴를 다시 발명하지 마라.
디자인 패턴(Design Pattern)이란?
디자인 패턴은 소프트웨어 디자인에서 자주 발생하는 문제들에 대해 재사용이 가능한 해결책이다.
우리가 일상에서 자주 접하는 문제는 분명 다른 사람에게도 일어났었을 것이며, 지금도 일어나고 있을 것이다.
이런 문제을 해결하는 데에 사용할 수 있는, 전형적인 해결 방식을 일반화하고 문서화시킨 게 디자인 패턴이다.
디자인 패턴은 특정 문제를 해결하는 일반적인 방법을 제시한다.
다르게 말하면, 특정 상황에 특화된 해결책이 아닌, 보다 일반적으로 적용 가능한 방법을 제시한다는 것이다.
물론 다양한 소프트웨어 시스템에서 사용될 수 있도록 어떤 프로그래밍 언어나 도구에도 적용이 가능하도록 설계되어 있다.
또, 디자인 패턴은 명확하게 문서화되어 있다. 다른 개발자들이 쉽게 이해하고 적용할 수 있도록 패턴 이름, 문제 설명, 해결 방법, 구현 예제 등으로 구성되어 있다.
이러한 디자인 패턴을 사용하면 소프트웨어 시스템을 보다 유연하고 확장 가능하게 설계할 수 있다. 새로운 문제(요구사항, 변경사항 등)에 쉽고 빠르게 대처가 가능하다. 개발자들이 공통된 디자인 언어를 공유하고 이해함으로써, 코드의 일관성을 유지하고 유지보수성을 향상시키는 데 중요한 역할을 한다.
따라서 디자인 패턴은 현대의 모든 소프트웨어 개발에서 필수적인 개념이다!
디자인 패턴(Design Pattern)의 역사
디자인 패턴의 개념이 소프트웨어 공학 분야에서 처음으로 명확히 정리된 것은 1994년에 4명의 컴퓨터 과학 연구자들인 Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides (일명 "Gang of Four, 또는 GoF 또는 사인방"이라 불린다)가 쓴 서적 Design Patterns: Elements of Reusable Object-Oriented Software (디자인 패턴: 재이용 가능한 객체지향 소프트웨어의 요소)이 출판되면서부터였다.
이 책은 객체지향 소프트웨어 개방에서 자주 발생하는 문제들을 해결하기 위한 23가지 디자인 패턴을 소개하였고, 이후 디자인 패턴이라는 개념이 널리 퍼지게 되었다고 한다.
🔎 TMI
- GoF는 "사인방"을 뜻하는 Gang of Four의 약자이며 에릭 감마, 리차드 헬름, 랄프 존슨, 존 블리시디스, 이 네 명을 지칭한다.
- 사실 소프트웨어 공학 분야에서 디자인 패턴이 처음 생겨난건 아니다. 건축학에서 특정 구조나 문제를 해결하기 위한 일반적인 해결책을 패턴으로서 정리하여 사용했었다. 이러한 개념이 소프트웨어 개발로 확장되어 구체화된 것이 바로 디자인 패턴이다!
GoF 디자인 패턴 분류
Gang of Four(GoF) 책에서 소개된 디자인 패턴은 목적에 따라 크게 3가지로 분류된다.
생성 패턴(5개), 구조 패턴(7개), 행위 패턴(11개)으로 총 23개의 패턴이 있다.
- 생성 패턴 (Creational Pattern)
- 객체의 생성 메커니즘을 다루며, 객체들을 생성하는 방식이나 객체 생성 시점을 결정하는 패턴
- 구조 패턴 (Structural Pattern)
- 클래스와 객체를 조합하여 더 큰 구조를 만드는 방법에 대한 패턴
- 행위 패턴 (Behavioral Pattern)
- 객체나 클래스 사이의 상호작용과 책임 분배 방법을 정의한 패턴
1. 생성 패턴 (Creational Pattern)
| (1) 추상 팩토리 (Abstract Factory) | - 구체적인 클래스에 의존하지 않고, 인터페이스를 통해 서로 연관 객체들의 그룹으로 생성하여 추상적으로 표현함 |
| (2) 빌더 (Builder) | - 작게 분리된 인스턴스를 건축하듯 조합하여 객체를 생성함 |
| (3) 팩토리 메서드 (Factory Method) | - 객체 생성을 서브 클래스로 분리해 처리하도록 캡슐화 함 - 상위 클래스에서 인터페이스만 정의하고, 실제 생성은 서브클래스에서 구현함 |
| (4) 프로토타입 (Prototype) | - 원본 객체를 복제하여 객체를 생성함 |
| (5) 싱글톤 (Singleton) | - 클래스가 하나의 인스턴스만 생성할 수 있음 - 생성된 객체는 어디서든 참조할 수 있지만, 동시에는 참조할 수 없음 |
2. 구조 패턴 (Structural Pattern)
| (1) 어댑터 (Adapter) | - 호환성 없는 클래스들의 인터페이스를 다른 클래스가 이용할 수 있도록 변환 |
| (2) 브리지 (Bridge) | - 구현부에서 추상층을 분리함 (독립적 확장) - 기능과 구현을 별도의 클래스로 구현함 |
| (3) 컴포지트 (Comsite) | - 복합 객체와 단일 객체를 구분 없이 다룰 때 사용함 - 객체들을 트리 구조로 구성 |
| (4) 데코레이터 (Decorator) | - 객체에 객체를 결합시켜 기능을 확장함 |
| (5) 퍼사드 (Facade) | - 복잡한 서브 클래스들을 피해 더 상위에 인터페이스를 구성함 |
| (6) 플라이웨이트 (Flyweight) | - 유사 객체들 사이에 가능한 많은 데이터를 공유해 사용함 - 메모리 절약 패턴 |
| (7) 프록시 (Proxy) | - 접근이 어려운 객체에 대한 인터페이스 역할을 함 |
3. 행위 패턴 (Behavioral Pattern)
| (1) 책임 연쇄 (Chain of Responsibility) | - 객체가 요청을 처리하지 못하면 다음 객체로 넘어감 - 책임 넘기기 |
| (2) 커맨드 (Command) | - 요청을 객체 형태로 캡슐화하여, 요청에 사용되는 각종 명령어들을 클래스로 분리함 |
| (3) 인터프리터 (Interpreter) | - 언어에 문법 표현을 정의 - 주로 SQL, 통신 프로토콜에 사용 |
| (4) 반복자 (Iterator) | - 접근이 잦은 객체에 대해 동일한 인터페이스 사용 |
| (5) 중재자 (Mediator) | - 객체들 사이의 복잡한 상호작용을 캡슐화함 - 객체 사이의 의존성과 결합도를 낮춤 |
| (6) 메멘토 (Memento) | - 복원을 위해 특정 시점에서 객체 내부 상태를 객체화해서 저장 - 되돌리기(Undo) 기능 구현에 사용 |
| (7) 옵서버 (Observer) | - 객체의 변화를 상속 되어있는 다른 객체들에게 변화된 상태를 알림 |
| (8) 상태 (State) | - 상태에 따라 동작을 다르게 처리 |
| (9) 전략 (Strategy) | - 동일한 계열의 알고리즘들을 캡슐화하여 상호교환함 |
| (10) 템플릿 메서드 (Template Method) | - 상위 클래스에서 알고리즘의 구조를 정의하고, 하위 클래스에서 구체적으로 처리를 함 |
| (11) 방문자 (Visitor) | - 클래스들의 복잡한 데이터 구조에서 처리 기능을 분리 - 분리된 처리기능은 각 클래스를 방문하여 처리함 |
'💾 Computer Science > Software Engineering' 카테고리의 다른 글
| [CS/Design Pattern] GoF 디자인 패턴 | 생성 패턴(Creational Pattern) 5가지 정리 (0) | 2024.07.10 |
|---|---|
| [CS/OOP] 객체지향 프로그래밍과 절차지향 프로그래밍의 차이 (0) | 2024.07.08 |
| [CS/OOP] 객체지향 설계의 5가지 기본 원칙 SOLID (0) | 2024.07.08 |
