[SW 설계] 디자인 패턴 (Design Pattern)

 

📍 디자인 패턴 개념

디자인 패턴은 반복적으로 나타나는 문제들을 해결해 온 전문가들의 경험을 모아서 정리한 일관된 솔루션으로 설계의 재사용을 통해 생산성 향상을 위한 기법이라 할 수 있다. 또한, 프로그래머들이 유용하다고 생각되는 객체들간의 일반적인 상호작용 방법들을 모은 목록이라 할 수 있다. 디자인 패턴은 GoF(Gang of Four) 의 분류가 많이 활용되고 있음.

 

📍 디자인 패턴 구성

① 패턴이름 : 설계의 의도를 표현하며 한 두 단어로 설계문제와 해법을 서술한다.

② 문제 : 해결해야할 문제와 그 배경을 설명하며 언제 패턴을 사용하는 지를 서술한다.

③ 해법 : 설계의 구성 요소와 그 요소들 간의 관계, 책임, 협력관계를 서술한다.

④ 결과 : 디자인 패턴을 적용해서 얻는 결과와 장점/단점을 서술한다. 

 

📍 GoF(Gang of Four) 디자인 패턴의 분류

 

1) 패턴이 수행하는 목적에 따른 분류

	특성	패턴 종류
생성패턴	시스템이 어떤 구체 클래스를 사용하는지에 대한 정보를 캡술화한다.	Singleton, Factory Method, Abstract Factory, Prototype, Builder 패턴
구조패턴	다른 기능을 가진 객체가 협력에 의해 어떠한 역할을 수행할 때 객체를 조직화시키는 일반적인 방식을 제시한다.	Decorator, Adaptor, Composite, Facade, Proxy, Bridge, Flyweight 패턴
행위패턴	객체의 행위에 대한 조직화, 관리, 연합에 사용한다.	Strategy, Observer, State, Command, Iterator, Template, Method, Interprter 패턴

📌 생성패턴(Creational Pattern)

싱글턴 패턴(Singleton Pattern)

특정 클래스에 객체 인스턴스가 하나만 만들어지도록 해주는 패턴입니다. 싱글턴 패턴을 사용하면 전역 변수를 사용할 때와 마찬가지로 객체 인스턴스를 어디서든지 액세스 할 수 있게 만들 수 있습니다. 클래스 인스턴스를 하나만 만들고 그 인스턴스로의 전역 접근을 제공합니다.

 

추상 팩토리 패턴(Abstract Factory Pattern)

구상 클래스에 의존하지 않고도 서로 연관되거나 의존적인 객체로 이루어진 제품군을 생산하는 인터페이스를 제공합니다. 구상 클래스는 서브 클래스에서 만듭니다.

 

팩토리 메소드 패턴(Factory method Pattern)

객체를 생성할 때 필요한 인터페이스를 만듭니다. 어떤 클래스의 인스턴스를 만들지는 서브클래스에서 결정합니다. 팩토리 메소드 패턴을 사용하면 클래스 인스턴스 만드는 일을 서브클래스에게 맡기게 됩니다.

빌더 패턴(Builder Pattern)

제품을 여러 단계로 나눠서 만들도록 제품 생산 단계를 캡슐화하고 싶다면 빌더(Builder) 패턴을 사용하면 됩니다. 혹시 반복자 패턴을 아시나요? 그 패턴을 사용하면 반복 작업을 별도의 객체로 캡슐화해서 컬렉션의 내부 구조를 클라이언트로부터 보호할 수 있습니다. 여기에서도 똑같은 아이디어를 사용합니다. 계획표 작성을 객체(빌더라고 부름)에 캡슐화해서 클라이언트가 빌더에게 계획표 구조를 만들어 달라고 요청하도록 만드는 거죠.

 

프로토타입 패턴(Prototype Pattern)

어떤 클래스의 인스턴스를 만들 때 자원과 시간이 많이 들거나 복잡하다면 프로토타입 (Prototype)패턴을 쓰면 됩니다. 프로토타입 패턴을 사용하면 기존 인스턴스를 복사하기만 해도 새로운 인스턴스를 만들 수 있습니다(자바에서는 clone() 메소드를 사용하거나 역직렬화를 하면 되죠). 이 패턴의 가장 두드러진 특징은 클라이언트 코드에서 어떤 클래스의 인스턴스를 만드는지 전혀 모르는 상태에서도 새로운 인스턴스를 만들 수 있다는 점입니다.

 

📌 행동패턴(Behavioral Pattern)

템플릿 메소드 패턴(Template method Pattern)

알고리즘의 골격을 정의합니다. 템플릿 메소드를 사용하면 알고리즘 일부 단계를 서브클래스에서 구현할 수 있으며, 알고리즘의 구조는 그대로 유지하면서 알고리즘의 특정 단계를 서브클래스에서 재정의할 수도 있습니다.

싱글턴 패턴(Singleton Pattern)

위 내용 동일

 

상태 패턴(State Pattern)

상태 패턴을 사용하면 객체의 내부 상태가 바뀜에 따라서 객체의 행동을 바꿀 수 있습니다. 마치 객체의 클래스가 바뀌는 것과 같은 결과를 얻을 수 있습니다.

 

반복자 패턴(iterator Pattern)

컬렉션의 구현 방법을 노출하지 않으면서 집합체 내의 모든 항목에 접근하는 방법을 제공합니다.

전략 패턴(Strategy Pattern)

알고리즘군을 정의하고 캡슐화해서 각각의 알고리즘군을 수정해서 쓸 수 있게 해 줍니다. 전략 패턴을 사용하면 클라이언트로부터 알고리즘을 분리해서 독립적으로 변경할 수 있습니다.

 

옵저버 패턴(observer Pattern)

한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체에게 연락이 가고 자동으로 내용이 갱신되는 방식으로 일대다 의존성을 정의합니다.

인터프리터 패턴(Interpreter Pattern)

어떤 언어의 인터프리터를 만들 때는 인터프리터(Interpreter) 패턴을 사용하면 됩니다. 인터프리터 패턴은 문법과 구문을 번역하는 인터프리터 클래스를 기반으로 간단한 언어를 정의합니다. 언어에 속하는 규칙을 나타내는 클래스를 사용해서 언어를 표현합니다. 오리 언어를 클래스로 표현하면 다음과 같습니다. 문법과 직접적으로 대응한다는 사실을 확인할 수 있습니다.

📌 구조패턴(Stuctural Pattern)

 

데코레이터 패턴(Decorator Pattern)

데코레이터 패턴으로 객체에 추가 요소를 동적으로 더할 수 있습니다. 데코레이터를 사용하면 서브클래스를 만들 때보다 훨씬 유연하게 기능을 확장할 수 있습니다.

프록시 패턴(Proxy Pattern)

특정 객체로의 접근을 제어하는 대리인(특정 객체를 대변하는 객체)을 제공합니다.

 

컴포지트 패턴(Composite Pattern)

컴포지트 패턴으로 객체를 트리구조로 구성해서 부분-전체 계층구조를 구현합니다. 컴포지트 패턴을 사용하면 클라이언트에서 개별 객체와 복합 객체를 똑같은 방법으로 다룰 수 있습니다.

 

어댑터 패턴(Adapter Pattern)

특정 클래스 인터페이스를 클라이언트에서 요구하는 다른 인터페이스로 변환합니다. 인터페이스가 호환되지 않아 같이 쓸 수 없었던 클래스를 사용할 수 있게 도와줍니다.

 

퍼사드 패턴(facade Pattern)

서브시스템에 있는 일련의 인터페이스를 통합 인터페이스로 묶어줍니다. 또한 고수준 인터페이스도 정의하므로 서브시스템을 더 편리하게 사용할 수 있습니다.

 

브리지 패턴(Bridge Pattern)

구현과 더불어 추상화 부분까지 변경해야 한다면 브리지(Bridge) 패턴을 쓰면 됩니다. 브리지 패턴을 사용하면 추상화된 부분과 구현 부분을 서로 다른 클래스 계층구조로 분리해서 그 둘을 모두 변경할 수 있습니다.

 

플라이웨이트 패턴(Flyweight Pattern)

어떤 클래스의 인스턴스 하나로 여러 개의 ‘가상 인스턴스’를 제공하고 싶다면 플라이웨이트 (Flyweight) 패턴을 사용하면 됩니다. Tree 객체를 수 천 개 만드는 대신 시스템을 조금 고쳐서 Tree의 인스턴스는 하나만 만들고 모든 나무의 상태를 클라이언트 객체가 관리하도록 하면 어떨까요? 이게 바로 플라이웨이트 패턴입니다.

2) 패턴이 다루는 영역에 따른 분류

분류	특성	패턴 종류
클래스패턴	클래스 간 상속 관계에 대한 정의를 수행하는 패턴이다. 객체를 생성하는 책임의 일부를 서브 클래스가 담당(상속)한다.	TemplateMethod, Factroymethod, Adapter, Interprter
객체패턴	객체 사이의 관련성을 다루는 패턴이다. 객체를 생성하는 책임의 일부를 다른 객체에게 위임한다.	Strategy, Observer, Decorator, Proxy, Composite, Iterator, State

 

📍 MVC(Model View Controller) 패턴

1) MVC 패턴 개념

소프트웨어 공학에서 사용되는 소프트웨어 디자인 패턴으로 사용자 인터페이스로부터 비즈니스 로직을 분리하여 애플리케이션의 시각적 요소나 그 이면에 실행되는 비즈니스 로직을 서로 영향 없이 쉽게 고칠 수 있는 애플리케이션을 만들 수 있다.

MVC에서 모델은 애플리케이션의 정보(데이터)를 나타내며, 뷰는 텍스트 체크박스 항목 등과 같은 사용자 인터페이스 요소를 나타내고, 컨트롤러는 데이터와 비즈니스 로직 사이의 상호동작을 관리한다.

 

2) MVC 패턴 구성

- 컨트롤러(Controller)는 모델에 명령을 보냄으로써 모델의 상태를 변경할 수 있다. (ex. 워드 프로세서에서 문서를 편집하는 것) 또한, 컨트롤러가 관련된 뷰에 명령을 보냄으로써 모델의 표시방법을 바꿀 수 있다.

 

- 모델(Model)은 모델의 상태에 변화가 있을 때 컨트롤러와 뷰에 이를 통보한다. 이와 같은 통보를 통해 뷰는 최신의 결과를 보여줄 수 있고, 컨트롤러는 모델의 변화에 따른 적용 가능한 명령을 추가 제거 수정할 수 있다. 어떤 MVC 구현에서는 통보 대신 뷰나 컨트롤러가 직접 모델의 상태를 읽어오기도 한다.

 

- 뷰(View)는 사용자가 볼 결과물을 생성하기 위해 모델로부터 정보를 얻어 온다.

 

 

 

 

https://www.hanbit.co.kr/channel/category/category_view.html?cms_code=CMS5781398544 

[Design pattern] 알아두면 유용한 9가지 GoF 디자인 패턴 정리