🔶 디자인 패턴이란?
Don't reinvent the wheel.
패턴이란 각기 다른 소프트웨어 모듈이나 기능을 가진 다양한 응용 소프트웨어 시스템들을 개발할 때도 서로 간에 공통되는 설계 문제가 존재하며 이를 처리하는 해결책 사이에도 공통점이 있다. 이러한 유사점을 패턴이라 한다. 또한, 공통의 언어를 만들어주며 팀원 사이의 의사 소통을 원활하게 해주는 아주 중요한 역할을 한다.
디자인 패턴은 자주 사용하는 설계 형태를 정형화해서 이를 유형별로 설계 템플릿을 만들어둔 것을 말한다. 디자인 패턴을 사용하면 효율성과 재사용성을 높일 수 있다. 디자인 패턴으로 만들려면 유사한 프로젝트를 수행하면서 적용한 설계 노하우를 분류하여 정리하고 이름을 붙여, 나중에 초보자도 쉽게 재사용할 수 있도록 사용 지침 등도 포함하여 저장해놓아야 한다.
디자인 패턴은 알고리즘처럼 프로그램 코드로 변환하여 바로 사용할 수 있는 것은 아니지만 유사한 상황에서 구조적인 문제를 해결할 수 있는 방안을 제시해준다. 결국 디자인 패턴은 많은 개발자들이 경험으로 체득한 설계 지식을 검증하고 이를 추상화하여 일반화한 템플릿이라 하겠다.
🔶 디자인 패턴 구조
👉 콘텍스트(context)
문제가 발생하는 여어 상황을 기술한다. 즉, 패턴이 적용될 수 있는 상황을 나타낸다.
경우에 따라서는 패턴이 유용하지 못한 상황을 나타내기도 한다.
👉 문제(problem)
패턴이 적용되어 해결될 필요가 있는 여러 디자인 이슈들을 기술한다.
이때 여러 제약 사항과 영향력도 문제 해결을 위해 고려해야 한다.
👉 해결(solution)
문제를 해결하도록 설계를 구성하는 요소들과 그 요소들 사이의 관계, 책임, 협력 관계를 기술한다.
해결은 반드시 구체적인 구현 방법이나 언어에 의존적이지 않으며 다양한 상황에 적용할 수 있는 일종의 템플릿이다.
🔶 디자인 패턴 종류
GoF 디자인 패턴
👉 GoF(Gang of Four)라 불리는 사람들 : 에리히 감마(Erich Gamma), 리차드 헬름(Richard Helm), 랄프 존슨(Ralph Johnson), 존 블리시디스(John Vissides)
👉 소프트웨어 개발 영역에서 디자인 패턴을 구체화하고 체계화한 사람들
23가지 디자인 패턴을 정리하고 각각의 디자인 패턴을 생성, 구조, 행위 3가지로 분류했다.
생성(Creational) 패턴
객체 생성에 관련된 패턴
(객체의 생성과 조합을 캡슐화해 특정 객체가 생성되거나 변경되어도 프로그램 구조에 영향을 크게 받지 않도록 유연성을 제공한다)
-
추상 팩토리(Abstract Factory)
구체적인 클래스에 의존하지 않고 서로 연관되거나 의존적인 객체들의 조합을 만드는 인터페이스를 제공하는 패턴 -
빌더(Builder)
복합 객체의 생성 과정과 표현 방법을 분리하여 동일한 생성 절차에서 서로 다른 표현 결과를 만들 수 있게 하는 패턴 -
팩토리 매서드(Factory Method)
객체 생성 처리를 서브 클래스로 분리해 처리하도록 캡슐화하는 패턴(Virtual-Constructor 패턴이라고도 함) -> Dependency Inversion Principle -
프로토타입(Prototype)
생성할 객체들의 타입이 프로토타입인 인스턴스로부터 결정되도록 하며, 인스턴스는 새 객체를 만들기 위해 자신을 복제하는 패턴 -
싱글턴(Singleton)
전역 변수를 사용하지 않고 객체를 하나만 생성하도록 하며, 생성된 객체를 어디에서든지 참조할 수 있도록 하는 패턴
구조(Structural) 패턴
클래스나 객체를 조합해 더 큰 구조를 만드는 패턴
(예를 들어 서로 다른 인터페이스를 지닌 2개의 객체를 묶어 단일 인터페이스를 제공하거나 객체들을 서로 묶어 새로운 기능을 제공한다)
-
어댑터(Adapter)
인터페이스가 호환되지 않는 클래스를 함께 사용하도록 하는 패턴 -
브리지(Bridge)
구현부에서 추상층을 분리하여 각자 독립적으로 변형할 수 있게 하여 결합도를 낮춘 패턴 -
컴포지트(Composite)
여러 개의 객체들로 구성된 복합 객체와 단일 객체를 클라이언트에서 구별 없이 동일하게 다루게 해주는 패턴 -
데코레이터(Decorator)
객체의 결합을 통해 기능을 동적으로 유연하게 확장할 수 있게 해주는 패턴 -> Open-Closed Principle -
퍼사드(Facade)
서브 시스템에 있는 인터페이스 집합에 통합된 하나의 인터페이스를 제공하고 서브 시스템을 좀 더 쉽게 사용하기 위해 고수준의 인터페이스를 정의하는 패턴 -
플라이웨이트(Flyweight)
동일하거나 유사한 객체들 사이에 가능한 많은 데이터를 서로 공유하여 사용하도록 하여 메모리 사용량을 최소화하는 패턴 -
프록시(Proxy)
어떤 다른 객체로 접근하는 것을 통제하기 위해 객체의 대리자를 이용하여 원래 객체의 작업을 대신 처리하는 패턴
행위(Behavioral) 패턴
객체나 클래스 사이의 알고리즘이나 책임 분배에 관련된 패턴
(한 객체가 혼자 수행할 수 없는 작업을 여러 개의 객체로 어떻게 분배하는지, 또 그렇게 하면서도 객체 사이의 결합도를 최소화하는 것에 중점을 둔다)
-
책임 연쇄(Chain of Responsibility)
객체들끼리 연결 고리를 만들어 내부적으로 전달하는 패턴 -
커맨드(Command)
요청을 캡슐화함으로써 요청에 필요한 정보를 주어진 여러 기능을 실행할 수 있는 재사용성이 높은 클래스를 설계하는 패턴
적용 예시) Thread -
인터프리터(Interpreter)
언어 규칙 클래스를 이용하는 패턴 -
반복자(Iterator)
내부 표현은 보여주지 않고 모든 항목에 순차적으로 접근하는 패턴
적용 예시) Collection 객체들 -
중재자(Mediator)
한 집합에 속해있는 객체들의 상호작용을 캡슐화하여 복잡한 관계를 단순화한 패턴 -
메멘토(Memento)
객체를 이전 상태로 되돌릴 수 있는 기능을 제공하는 패턴 -
옵저버(Observer)
한 객체의 상태 변화에 따라 다른 객체의 상태도 연동되도록 일대다 객체 의존 관계를 구성하는 패턴
적용 예시) MVC 패턴 -
상태(State)
객체의 상태에 따라 객체의 행위 내용을 변경(동일한 동작을 다르게 처리)해주는 패턴 -
전략(Strategy)
특정한 계열의 알고리즘을 정의하고 각 알고리즘을 캡슐화하여 해당 계열 안에서 상호 교체 가능하게 하는 패턴 -
템플릿 매서드(Template Method)
어떤 작업을 처리하는 일부분을 서브 클래스로 캡슐화해 전체 일을 수행하는 구조는 바꾸지 않으면서 특정 단계에서 수행하는 내역을 바꾸는 패턴
적용 예시) Spring에서 DispatcherServlet의 doService 함수 -
비지터(Visitor)
구조를 수정하지 않고도 실질적으로 새로운 동작을 기존의 객체 구조에 추가할 수 있게 알고리즘을 객체 구조에서 분리시키는 패턴
🔶 디자인 패턴 장점
-
개발자(설계자) 간의 원활한 의사소통
설계자들은 여러 가지 디자인 패턴의 특성을 잘 알고 있어 문제 해결을 위해 서로 대화를 나눌 때 어떤 디자인 패턴을 사용하면 좋을지 충분한 해결책을 논의할 수 있다. -
소프트웨어 구조 파악 용이
개발자들은 디자인 패턴의 특성을 잘 알고 있기 때문에 어떤 디자인 패턴이 설계할 때 사용되었는지 알면 소프트웨어 전체 구조를 쉽게 파악할 수 있다. -
재사용을 통한 개발 시간 단축
이미 만들어놓은 디자인 패턴을 사용하므로 처음부터 만들어야 하는 수고를 덜기 때문에 그만큼의 개발 시간을 줄일 수 있다. -
설계 변경 요청에 대한 유연한 대처
사용자의 지속적인 기능 추가 요청, 환경 변화 등의 여러 가지 이유로 설계를 변경해야 할 때가 많다. 이때 디자인 패턴을 사용하여 설계했다면 설계 변경 요청에 대해 쉽고 빠르게 대처할 수 있다.
🔶 디자인 패턴 단점
-
객체지향 설계/구현 위주
디자인 패턴은 객체지향 설계/구현에 많이 사용된다. C 언어를 주로 사용하는 구조적 설계/구현에서도 사용할 수 있지만 너무 복잡해서 큰 도움이 되지 않는다. -
초기 투자 비용 부담
디자인 패턴을 적용하여 설계하면 디자인 패턴을 사용하지 않는 경우보다 초기에 시간과 노력이 많이 든다.
