[ENG][아키텍처]Design Patterns - Pattern

Abstract Factory

구체적인 클래스를 지정하지 않고 관련성을 갖는 객체들의 집합, 서로 독립적인 객체들의 집합을 생성할 수 있는 인터페이스를 제공하는 패턴.
위임, DIP, Composition

 

Adapter

Composit
클래스의 인터페이스를 사용자가 기대하는 다른 인터페이스로 변환하는 패턴으로, 호환성이 없는 인터페이스 때문에 함께 동작할 수 없는 클래스들이 함께 작동하도록 해 줍니다.

 

Bridge

구현부에서 추상층을 분리하여 각자 독립적으로 변형할 수 있게 하는 패턴.
추상적 개념과 이에 대한 구현 사이의 지속적인 종속 관계를 피하고 싶을 때 사용. 추상적 개념과 구현 모두가 독립적으로 서브클래싱을 통해 확장되어야 할때 사용.

 

어댑터 패턴과 브릿지 패턴의 차이는?

다른점, 어댑터는 인터페이스가 다를경우 해결하려고, 디자인된 이후에 적용하는 목적, 브릿지는 그런 구조적인 문제가 생길까바 미리 만들어두는 디자인, 미리 대비하는 패턴
구조적으로 어댑터는 간단한싱글 인터페이스, 브릿지는 복잡한 분리, 전체를 앱스트랙트 시킨다.

 

Builder

Composition
복잡한 객체의 생성 과정과 표현 방법을 분리하여 동일한 생성 절차에서 서로 다른 표현 결과를 만들 수 있게 하는 패턴.

빌더 패턴과 팩토리 패턴의 차이점을 서술하세요.
팩토리 패턴이랑 비교하면 클라이언트가 원하는 결과물이 다름
빌더는 스텝 바이 스텝으로 만드는 프로세스에 중점, 맨 마지막에 결과가 합쳐져서 나옴, 하나의 군에대한 생성하는 다양한 방식에 대한 정보를 감춘다
팩토리는 요청을 할 때마다 즉각적으로 리턴한다음 나중에 prepare로 만드는 것
여러 군들에 대한 생성을 감춘다

빌더는
- 메인 클래스의 인스턴스 생성전. 한번에 클래스 생성 및 처리
- 클래스 생성시 인자값이 클래스 (데이터) 구조와 일치 (C# JSON ??)
- 메인 클래스의 인스턴스가. 각 클래스와 같은 기능
- 복잡한 객체의 단계별 생성에 중점
- 마지막 단계에서 생성한 제품 반환

팩토리는
- 메인 클래스의 인스턴스 생성 후. 각 클래스를 생성하여 사용
- 또는. 메인 클래스의 인자값에 클래스를 생성하여 사용
- 메인 클래스의 인스턴스가. 각 클래스와 같은 기능
- 제품의 유사군들의 존재하는 경우 유연한 설계에 중점
- 만드는 즉시 제품을 반환

 

Chain Of Responsibility

요청을 처리할 수 있는 기회를 하나 이상의 객체에게 부여하여 요청을 보내는 객체와 그 요청을 받는 객체 사이의 결합을 피하는 패턴.
요청을 받을 수 있는 객체를 연쇄적으로 묶고, 실제 요청을 처리할 객체를 만날 때까지 객체 고리를 따라서 요청을 전달.
요구를 처리하는 객체들을 사슬 모양으로 늘어놓고, 요청이 들어오면 누가 처리할 지를 차례차례 체크해 나가는 Chain of Responsibility 패턴
- 장점 : sender와 receiver의 디커플링, 추가에 유연함
- 단점 : client는 누가 request를 handle하는지 알 수 없다.
- Java의 try-catch 패턴

 

Command

DIP
실행될 기능을 캡슐화함으로써 주어진 여러 기능을 실행할 수 있는 재사용성이 높은 클래스를 설계하는 패턴
즉, 이벤트가 발생했을 때 실행될 기능이 다양하면서도 변경이 필요한 경우에 이벤트를 발생시키는 클래스를 변경하지 않고 재사용하고자 할 때 유용하다.

Request를 캡슐화 시킵니다. 클라이언트는 command 객체를 invoker에 넣어 실행할 수 있습니다. 동작시키는 Invoker와 전달받는 Receiver를 디커플링 시킵니다.

 

Composite

DIP
객체들의 관계를 트리구조로 구성하여 부분-전체 계층을 표현하는 패턴. 사용자가 단일 객체와 복합 객체 모두 동일하게 다룸.

 

Decorator

OCP
주어진 상황 및 용도에 따라 어떤 객체에 책임을 덧붙이는 패턴. 기능 확장이 필요할 때 서브클래싱 대신 쓸 수 있는 유연한 대안이 될 수 있다.

 

Decorator 객체가 Inheritance와 Association이 모두 존재해야하는 이유

Inheritance : 감싸는 기능, 확장에서 모든 type이 같아야하기 때문에
Association : 객체를 감싸서 기능을 추가 확장하므로

 

Facade

서브시스템에 있는 인터페이스 집합에 대해서 하나의 통합된 인터페이스를 제공하는 패턴. 서브시스템을 좀더 사용하기 편하게 만드는 상위 수준의 인터페이스를 정의합니다.

 

Factory Method

DIP
객체를 생성하는 인터페이스는 미리 정하되, 인스턴스를 만들 클래스의 결정은 서브클래스 쪽에서 내리는 패턴. (서브클래스에서 클래스의 인스턴스 생성)

 

AbstractFactory와 무엇이 다른가요?

팩토리메소드는 상속, 템플릿메소드 패턴을 포함한다
if( type == "z"){ pizza = new Zpizza();

Abtract 팩토리는 델리게이션, 팩토리를 이용해서 만드는것만 전문적인 클래스를 사용한다, 한 레벨 더 높은 추상화 = 컴포지션 + 델리게이션
pizza = factory.createPizza();

 

Flyweight

크기가 큰 객체가 여러 개 있을 때, 공유를 통해 이들을 효율적으로 지원하는 패턴. 해쉬 테이블에 자주 사용되고 반복적이며 메모리가 큰 것을 저장해두고 재사용하는것

인스턴스를 가능한 한 공유시켜서, 쓸데없이 new를 하지 않도록 한다. – 인스턴스가 필요할 때 마다 new를 하는 것이 아니라, 이미 만들어져 있는 인스턴스를 이용할 수 있으면 공유하자. 
Prototype은 복제를 하는 것이고 Flyweight는 있는것 그대로 쓴다.

 

Iterator

 SRP, DIP,
내부 표현부를 노출하지 않고 어떤 객체 집합에 속한 원소들을 순차적으로 접근할 수 있는 방법을 제공하는 패턴.

 

Interpreter

주어진 언어에 대해, 그 언어의 문법을 위한 표현 수단을 정의하고, 그 표현 수단을 사용하여 해당 언어로 작성된 문장을 해석하는 해석기를 정의하는 패턴.

프로그램이 해결하려고 하는 문제를 간단한 ‘미니 언어’로 표현함 
– 구체적인 문제를 미니 언어로 쓰여진 ‘미니 프로그램’으로 표현한다.
– 미니 프로그램을 자바 언어로 ‘통역’하는 역할을 하는 프로그램을 만 든다.
– 통역 프로그램은 미니 언어를 이해하고 미니 프로그램을 해석 및 실 행한다.
– 해결해야 할 문제에 변화가 생겼을 때, 프로그램을 고치지 않고 미니 프로그램을 고쳐서 해결한다. 

 

Mediator

Loosely coupled, 코드 리유즈 어려움
한 집합에 속해있는 객체들의 상호작용을 캡슐화하는 객체를 정의하는 패턴.
객체들이 직접 서로를 참조하지 않도록 함으로써 객체들 사이의 Loose coupling을 촉진시키며, 개발자가 객체들의 상호작용을 독립적으로 다양화시킬 수 있게 만듭니다.

 

Memento

현재 객체의 상태를 기록하여 보존하기 위한 Memento 패턴 
– Caretaker 역할은 중간 중간 Originator 역할에게 부탁하여 ‘현 재의 상태’를 표현하는 Memento 역할을 만든다. 
– Caretaker 역할은 필요할 때 서랍 안에서 Memento 역할을 꺼 내서 Originator 역할에게 건네주면, 그 상태로 복원이 된다.

 

MVC

MVC (모델-뷰-컨트롤러) 는 사용자 인터페이스, 데이터 및 논리 제어를 구현하는데 널리 사용되는 소프트웨어 디자인 패턴입니다. 소프트웨어의 비즈니스 로직과 화면을 구분하는데 중점을 두고 있습니다. 이러한 "관심사 분리" 는 더나은 업무의 분리와 향상된 관리를 제공합니다.

 

Observer

Loosely coupled
객체들 사이에 일 대 다 의존 관계를 정의해 두어, 어떤 객체의 상태가 변할 때 그 객체에 의존성을 가진 다른 객체들이 그 변화를 통지받고 자동으로 갱신될 수 있게 만드는 패턴.
주체(Subject)와 감시자(Observer) 사이에서 주체의 변경이 일어났을 때 감시자에게 알려주어 변화되어야 하는 객체들에게 전달(Update)합니다.
cons : -> subject의 state가 바뀔때마다 noti가 올것임. 특정 상태일때만 알면 될때는 overhead가 될 수 있음. 그래서 ChangeManager를 중간에 둘수도 있겠다. 

Push VS Pull
Push 방식은 observer.update(data1, data2, data3); 와 같이 Observable에서 update메서드로 직접 넣어주는 방식. observer은 update의 인자로 넘어온 값들을 사용하게 된다. 

Pull 방식은 observer.update(this, arg); 와 같이 Observable 인스턴스를 보내고, observer.update 함수에서 observable.getXXX() 함수를 사용하여 가져가는 방식.

 

Prototype

생성할 객체의 종류를 명시하는 데에 원형이 되는(Prototypical) 인스턴스를 이용하고, 그 원형을 복사함으로써 새로운 객체를 생성하는 패턴.
클래스로부터 인스턴스를 새로 만드는 것이 아니라, 현재 존재 하는 인스턴스를 복사(복제)해서 새로운 인스턴스를 만들 필요 가 있을 때, 이 작업을 편하게 하기 위해 사용한다

pros : 인스턴스를 만드는 복잡한 과정을 몰라도 되고 속도가 빠르다
cons : 복사본 자체를 만드는일 자체가 복잡할 수 있다.

객체를 빨리 생성하는 패턴

 

Proxy

어떤 다른 객체로 접근하는 것을 통제하기 위해서 그 객체의 대리자(Surrogate) 또는 Placeholder를 제공하는 패턴.

 

Proxy pattern의 활용되는 방식

Real subject가 필요한 경우에 생성될 수 있도록 컨트롤 하거나 생성되기 전까지 대리인 역할을 한다. Real subject가 생성되면 Client로부터의 요청사항을 Real subject로 전달한다.
Client와 Real subject가 서로 다른 주소체계에 있거나 Real subject가 생성하는데 오래걸리거나 비싸거나, Real subject에 접근하는 권한의 관리가 필요할 경우 활용된다.

- remote proxy : responsible for encoding a request and its arguments and for sending the encoded request to the real subject in a different address space – 
- virtual proxy : may cache additional information about the real subject so that they can postpone accessing it – 
- protection proxy : checks that the caller has the access permissions required to perform a request

원격 프록시 : 요청과 해당 인수를 인코딩하고 인코딩된 요청을 다른 주소 공간의 실제 주체에게 보내는 역할을 합니다.
- 가상 프록시 : 실제 주제에 대한 추가 정보를 캐시에 저장하여 액세스를 연기할 수 있습니다.
- 보호 프록시 : 호출자가 요청을 수행하는 데 필요한 액세스 권한이 있는지 확인합니다.

 

Singleton

어떤 클래스의 인스턴스는 오직 하나임을 보장하며, 이 인스턴스에 접근할 수 있는 전역적인 접촉점을 제공하는 패턴.

 

State

OCP, 위임, DIP
객체의 내부상태에 따라  스스로 행동을 변경할 수 있게끔 허가하는 패턴.
상태가 변할 때마다 서브클래스 중 하나의 인스턴스로 변경함.
 
장점으로는 한 State와 관계된 모든 동작들이 하나의 Object 안에 모두 모인다.
State 추가 시 다른 Object에 대한 수정 없이 하나의 Object만 추가되면 된다.
따라서 State에 따른 조건문 없이 관리가 가능하다.
단점으로는 State 수만큼 Object가 관리되어야 함으로 Object가 늘어나고,
State 안에 동작이 추가될 경우 모든 Object들에 대해서 추가되어야 해서 수정범위가 늘어나게 된다.

 

Strategy

Has a 관계가 아닌 Is a 관계로 코드 재사용성이 높다, Composition, Polymorphism, 위임, DIP,
같은 계열의 알고리즘군을 정의하고, 각각의 알고리즘을 캡슐화하여 교환해서 사용할 수 있도록 만든 패턴.
알고리즘을 사용하는 사용자와 상관없이 독립적으로 알고리즘을 다양하게
변경할 수 있게 합니다.

 

Strategy는 알고리즘이 다양하고 상호교환이 필요할 때 사용합니다.

 

Template Method

객체의 연산에는 알고리듬의 뼈대만을 정의하고 각 단계에서 수행할 구체적 처리는 서브클래스 쪽으로 미루는 패턴.
알고리즘의 구조 자체는 그대로 놔둔 채 알고리즘 각 단계의 처리를 서브클래스에서 재정의할 수 있게 합니다.

Template Method 패턴은 어떤 부분이 opened, closed 되어있나요?

Visit

객체 구조를 이루는 원소에 대해 수행할 연산을 표현하는 패턴.
연산을 적용할 원소의 클래스를 변경하지 않고도(구조 변경 없이) 새로운 연산을 정의(새로운 기능 추가)할 수 있게 합니다. 다양한 객체에 새로운 기능을 추가해야 하는데 캡슐화가 별로 중요하지 않은 경우에 사용.
데이터 구조와 처리를 분리하자. 
– 데이터 구조를 돌아다니는 “방문자”를 정의해서, 이 방문자가 “처리”를 담당하도록 하자. 
– 새로운 처리를 추가하고 싶을 때는, 새로운 “방문자”를 만든다.

 

Mediator VS Facade

Mediator는 Colleague간 복잡한 Communication을 간접적으로 서로 통신하는데 사용, Facade는 복잡한 Sub System의 Interface를 제공하여 클라이언트가 Sub System과의 디펜던시가 생기지 않도록 한다.
Mediator는 양방향 통신, Facade는 단방향 통신