디자인 패턴(Design Pattern) - 목적에 따른 분류

디자인 패턴이란? 

(소프트웨어) 디자인 패턴이란 특정 문맥에서 공통적으로 발생하는 문제에 대해 쓰이는 재사용 가능한 해결책

목적별로 일정한 패턴이 제시되어 있음

완전한 정답이 되는 알고리즘과 달리 현재 상황에 맞춰 최적화된 패턴을 결정하여 사용하는 것이 좋음 

대표적으로 구체화된 디자인 패턴은 GoF(Gang of Four) 에서 제시한 23개의 패턴이 있음 

 

* Gang of Four : Erich Gamma, Richard Helm, Ralph johnson, john Vissides, 총 4명을 일컬음 

 

디자인 패턴의 장점

개발자 간의 원활한 협업이 가능 

소프트웨어의 구조를 파악하기 용이함 

재사용을 통해 개발 시간 단축 

설계 변경이 있을 경우 비교적 원활하게 조치가 가능 

 

디자인 패턴은 개발자 세계에서 공용어 사전입니다. 개발자는 문제가 있을 때 머리속에서 해결안을 쥐어 짜내지 않아도
동료와 소통 할 수 있습니다. 로직을 런타임에 동적으로 어떻게 추가하는지 옆에 앉은 개발자에게 알려주고 싶다고요? 
일일이 단계별로 그림을 그려가며 괜히 오해할 필요 없이 간단한 한마디만 속삭이면 그만입니다. 
"자, 이건 장식자 패턴으로 해결해 보자" . 상대가 곧바로 알아들을 테니 더 이상 설명을 필요 없습니다. 
각자 패턴을 알고 있고 올바르게 사용하는 방법을 숙지하고 있으면 견고하고 유지보수 가능한 애플리케이션을 이미 개발하고 있는 셈입니다.

[ 출처 : Java EE - 디자인 패턴 ]  

 

권장도서

<GoF의 디자인 패턴 : 재 사용성을 지닌 객체지향 소프트웨어의 핵심요소>

<헤드 퍼스트 디자인 패턴> 

 

디자인 패턴의 단점 

객체지향적 설계를 고려하여 진행해야 함 

초기 투자 비용이 많이 들어감(돈 뿐만 아니라 시간 등 포함) 

 

디자인 패턴을 쓸데없이 과용하면 문제만 는다는 사실을 꼭 기억 하세요. 새로운 패턴을 배운 개발자는 곧장 어디든 적용해고픈 충동을 느끼기 마련인데 자칫 퍼사드나 괜히 복잡하기만 한 장식자 또는 싱글톤으로 프로젝트 코드를 도배하기 십상입니다. 디자인 패턴은 문제를 푸는 답안이므로 지금 문제가 있든가 앞으로 발생할 가능성이 없으면 굳이 패턴을 구현할 필요가 없습니다.
예를 들어, 작동 로직이 거의 바뀔 일 없는 객체에 장식자패턴을 씌우는 건 당장 개발 복잡도를 높을 뿐만 아니라 나중에 유지보수 할 때에도 끔찍한 악몽이 될 수 있습니다. 
[ 출처 : Java EE - 디자인 해턴 ]

 

GoF 디자인 패턴 

생성 패턴	구조 패턴	행동 패턴
Abstract Factory  Builder  Factory Method  Prototype  SIngleton	Adapter  Bridge  Composite  Decorator  Facade Flyweight  Proxy	Chain of Responsibility  Command  Interpreter  Iterator  Mediator  Memento  Observer  State  Strategy  Template Method Visitor

 

생성 패턴 

생성 패턴은 객체의 생성과 관련된 패턴 

특정 객체가 생성되거나 변경되어도 프로그램 구조에 영향을 최소화 할 수 있도록 유연성 제공 

 

 

생성패턴	의도
추상팩토리(Abstract Factory)	구체적인 클래스를 지정하지 않고 인터페이스를 통해 연관되는 객체를 묶어줌
빌더(Builder)	객체의 생성과 표현을 분리하여 객체를 생성
팩토리 메소드(Factory Method)	객체 생성을 서브클래스로 분리하여 위임(캡슐화)
프로토타입(Prototype)	원본 객체를 복사하여 객체를 생성(클론)
싱글톤(Singleton)	한 클래스마다 인스턴스를 하나만 생성하여 어디서든 참조

 

 

구조 패턴 

구조 패턴은 프로그램 내 자료 구조나 인터페이스 구조 등 프로그램 구조를 설계하는데 사용되는 패턴 클래스나 객체를 조합하여 더 큰 구조를 만들 수 있게 해줌

 

구조 패턴	의도
어댑터(Adapter)	클래스의 인터페이스를 어떤 클래스에서든 이용할 수 있도록 변환
브리지(Bridge)	구현부에서 추상층을 분리하여 각자 독립적으로 변형하고 확장할 수 있도록 함
컴포지트(Composite)	객체들의 관계를 트리구조로 구성하여 표현하는 방식으로 복합 객체와 단일 객체를 구분없이 다룸
데코레이터(Decorator)	주어진 상황에 따라 객체에 다른 객체를 덧붙임
파사드(Facade)	서브 시스템에 있는 인터페이스 집합에 대해 통합된 인터페이스 제공
플라이웨이트(Flyweight)	크기가 작은 여러개의 객체를 매번 생성하지 않고 최대한 공유하여 사용하도록 메모리 절약
프록시(Proxy)	실제 기능을 수행하는 객체 대신 가상의 객체를 사용해 로직의 흐름을 제어

 

 

행동(행위) 패턴 

행동 패턴은 반복적으로 사용되는 객체들의 커뮤니케이션을 패턴화 

객체 사이에 알고르짐 또는 책임을 분배하는 방법에 대해 정의됨 

결합도를 최소화 하는 것이 주 목적 

 

 

행동패턴	의도
챔임 연쇄(Chani of Responsibility)	요청을 받는 객체를 연쇄적으로 묶어 요청을 처리하는 객체를 만날때까지 객체 Chain을 따라 요청을 전달
커맨드(Command)	요청을 객체의 형태로 캡슐화하여 재사용하거나 취소
인터프리터(Interpreter)	특정 언어의  문법 표현을 정의
반복자(Iterator)	컬렉션 구현 방법을 노출하지 않으면서 모든 항목에 접근할 수 있는 방법을 제공
중재자(Mediater)	한 집합에 속해있는 객체들의 상호작용을 캡슐화하여 새로운 객체로 정의
메멘토(Memento)	객체가 특정 상태로 다시 되돌아올 수 있도록 내부 상태를 실체화
옵저버(Observer)	객체 상태가 변할 때 관련 객체들이 그 변화를 전달받아 자동으로 갱신
상태(State)	객체의 상태에 따라 동일한 동작을 다르게 처리
전략(Strategy)	동일 계열의 알고리즘 군을 정의하고 캡슐화하여 상호 교환이 가능하게 함
템플릿  메소드	상위 클래스는 알고리즘의 골격만을 작성하고 구체적인 처리는 서브 클래스로 위임
방문자(Visitor)	객체의 원소에 대해 수행할 연산을 분리하여 별도의 클래스로 구성

 

 

 

내용 출처 : https://www.youtube.com/watch?v=Mq4MwPXWarI