FIF's 코딩팩토리

기타 여러가지 패턴들 정리 본문

Back-End/Design Pattern(디자인 패턴)

기타 여러가지 패턴들 정리

FIF 2019. 6. 10. 16:36
반응형

 

브리지(Bridge) 패턴

구현 뿐만 아니라 추상화된 부분까지 변경시켜야 하는 경우에 사용하는 패턴이다.

 

추상화된 부분과 추상 클래스/인터페이스를 구현한 클래스를 서로 다른 클래스 계층구조에 집어넣음으로써 그 둘을 모두 변경시킬 수 있다.

 

브리지의 장점

1. 구현을 인터페이스에 완전히 결합시키지 않았기 때문에 구현과 추상화된 부분을 분리시킬 수 있다.

2. 추상화된 부분과 실제 구현 부분을 독립적으로 확장할 수 있습니다.

3. 추상화된 부분을 구현한 구상 클래스를 바꿔도 클라이언트 쪽에는 영향을 끼치지 않는다.

 

브리지의 활용법 및 단점

1. 여러 플랫폼에서 사용해야 할 그래픽스 및 윈도우 처리 시스템에서 유용하게 쓰인다.

2. 인터페이스와 실제 구현부를 서로 다른 방식으로 변경해야 하는 경우에 유용하게 쓰인다.

3. 디자인이 복잡해진다는 단점이 있다.

 

빌더(Builder) 패턴

제품을 여러 단계로 나눠서 만들 수 있도록 제품 생산 단계들을 캡슐화하고 싶을 때 사용하는 패턴이다.

 

이터레이터 패턴에서는 반복작업을 별도의 객체로 캡슐화함으로써 컬렉션의 내부 구조를 클라이언트로부터 보호할 수 있었다.

여기서도 같은 아이디를 사용한다.

여행 계획표를 만드는 일을 객체(빌더라고 부름)에 캡슐화 시켜서 클라이언트에서는 빌더한테 여행 계획표 구조를 만들어 달라고 요청하기만 하면 된다.

 

빌더의 장점

1. 복합 객체가 생성되는 과정을 캡슐화 한다.

2. 여러 단계와 다양한 절차를 통해서 객체를 만들 수 있다.(팩토리 패턴에서는 한 단계에서 모든걸 처리한다.)

3. 제품의 내부 구조를 클라이언트로부터 보호할 수 있다.

4. 클라이언트에서는 추상 인터페이스만 볼 수 있기 때문에 제품을 구현한 코드를 쉽게 바꿀 수 있다.

 

빌더 활용법 및 단점

1. 복합 객체 구조를 구축하기 위한 용도로 많이 쓰인다.

2. 팩토리를 사용하는 경우에 비해 객체를 만들기 위해서 클라이언트에 대해 더 많이 알아야 한다.

 

역할 사슬(CHAIN OF RESPONSIBILITY) 패턴

한 요청을 두 개 이상의 객체에서 처리하고 싶을 때 사용하는 패턴이다.

 

주어진 요청을 검토하기 위한 객체 사슬을 생성한다.

그 사슬에 속해 있는 각 객체에서는 자기가 받은 요청을 검사하여 직접 처리하거나 사슬에 들어있는 다른 객체한테 넘기게 된다.

 

역할 사슬의 장점

1. 요청을 보낸 쪽하고 받는 쪽을 분리시킬 수 있다.

2. 객체에서는 사슬의 구조를 몰라도 되고 그 사슬에 들어있는 다른 객체에 대한 직접적인 레퍼런스를 가질 필요도 없기 때문에 객체를 단순하게 만들 수 있다.

3. 사슬에 들어가는 객체를 바꾸거나 순서를 바꿈으로써 역할을 동적으로 추가/제거 할 수 있다.

 

역할 사슬 활용법 및 단점

1. 윈도우 시스템에서 마우스 클릭이나 키보드 이벤트를 처리할 때 흔히 쓰인다.

2. 요청이 반드시 수행된다는 보장이 없다는 단점이 있다. 사슬 끝까지 갔는데도 아무 객체에서도 처리해주지 않을 수 있다.(사실 이런 특성이 장점이 될 수도 있긴하다.)

3. 실행시에 과정을 살펴보거나 디버깅하기가 힘들 수 있다는 단점이 있다.

 

플라이 웨이트(FLYWEIGHT) 패턴

어떤 클래스의 인스턴스 한 개만 가지고 여러 개의 “가상 인스턴스”를 제공하고 싶을 때 사용하는 패턴이다.

 

단순 기능만 있는 객체가 있다고 할 때(시나리오상 Tree), 그 객체를 수 천 개 만드는 대신 시스템을 조금 고쳐 객체의 인스턴스는 하나만 만들고 모든 객체의 상태를 클라이언트 객체에서 관리하도록 하는 패턴이다.

 

플라이웨이트 패턴의 장점

1. 실행시에 객체 인스턴스의 개수를 줄여서 메모리를 절약할 수 있다.

2. 여러 “가상” 객체의 상태를 한 곳에 집중시켜 놓을 수 있다.

 

플라이웨이트 패턴 활용법 및 단점

1. 어떤 클래스의 인스턴스가 아주 많이 필요하지만 모두 똑 같은 방식으로 제어할 수 있는 경우에 유용하다.

2. 일단 이 패턴을 써서 구현해놓고 나면 특정 인스턴스만 다른 인스턴스와 다른 식으로 행동하도록 하는 것이 불가능 하다는 단점이 있다.

 

인터프리터(Interpreter) 패턴

어떤 언어에 대한 인터프리터를 만들 때는 인터프리터 패턴을 사용한다.

 

간단한 언어를 구현해야 하는 경우에, 인터프리터 패턴에서는 문법 및 그 구문을 번역하기 위한 인터프리터를 표현한 것을 클래스를 기반으로 정의한다.

언어에 속하는 각 규칙을 나타내는 클래스를 이용하여 언어를 표현하게 된다.

인터프리터 패턴의 장점

1. 각 문법 규칙을 클래스로 표현하기 때문에 언어를 쉽게 구현할 수 있다.

2. 문법이 클래스에 의해 표현되기 때문에 언어를 쉽게 변경하거나 확장할 수 있다.

3. 클래스 구조에 메소드만 추가하면 프로그램을 해석하는 기본 기능 외에 예쁘게 출력하는 기능이라던지 더 나은 프로그램 확인 기능 같은 새로운 기능을 추가할 수 있다.

 

인터프리터 활용법 및 단점

1. 간단한 언어를 구현할 때 인터프리터 패턴이 유용하다.

2. 문법이 간단하고 효율보다는 단순하게 만드는 것이 더 중요한 경우에 ㅇ용하다.

3. 스크립트 언어 및 프로그래밍 언어에서 모두 쓸 수 있다.

4. 문법 규칙의 개수가 많아지면 아주 복잡해진다는 단점이 있다. 그런 경우에는 파서/컴파일러가 생성기를 쓰는게 낫다.

 

미디에이터(Mediator) 패턴

서로 관련된 객체 사이의 복잡한 통신과 제어를 한 곳으로 집중시키고자 하는 경우 사용하는 패턴이다.

 

시스템에 미디에이터 패턴을 적용하면 가전제품 객체들을 훨씬 단순화 시킬 수 있다.

1. 상태가 바뀔 때 마다 미디에이터한테 알려준다.

2. 미디에이터에서 보낸 요청에 응답한다.

미디에이터를 추가하기 전에는 모든 객체들이 다른 객체들하고 서로 알고 있어야 했다.

하지만 미디에이터를 사용한 후로는 서로 완전히 분리될 수 있다.

미디에이터에는 모든 시스템을 제어할 수 있는 로직이 들어가있다.

기존 전자제품에 새로운 규칙을 추가해야 한다거나 새로운 가전제품을 가정 자동화 시스템에 추가하더라도 미디에이터만 고치면 된다.

 

미디에이터 패턴의 장점

1. 시스템하고 각 객체를 분리시킴으로써 재사용성을 획기적으로 향상시킬 수 있다.

2. 제어 로직을 한 군데 모아놨기 때문에 관리하기가 수월하다.

3. 시스템에 들어있는 객체 사이에서 오가는 메시지의 종류를 확 줄이고 단순화시킬 수 있다.

 

미디에이터 패턴 활용법 및 단점

1. 서로 연관된 GUI 구성요소들을 관리하기 위한 용도로 많이 쓰인다.

2. 디자인을 잘 하지 못하면 미디에이터 객체 자체가 너무 복잡해질 수 있다는 단점이 있다.

 

메멘토(MEMENTO) 패턴

객체를 이전의 상태로 복구시켜야 하는 경우에 사용한다.

예를 들어 사용자가 “작업 취소”를 요청하는 경우이다.

 

메멘토 패턴의 2가지 목적

1. 시스템에서 핵심적인 기능을 담당하는 객체의 중요한 상태 저장.

2. 핵심적인 객체의 캡슐화 유지.

 

메멘토 패턴의 장점

1. 저장된 상태를 핵심 객체와는 다른 별도의 객체에 보관하기 때문에 안전하다.

2. 핵심 객체의 데이터를 계속해서 캡슐화된 상태로 유지할 수 있다.

3. 복구 기능을 구현하기 쉽다.

 

메멘토 패턴 활용법 및 단점

1. 메멘토 객체를 써서 상태를 저장한다.

2. 상태를 저장하고 복구하는 데 시간이 오래 걸리 수 있다는 단점이 있다.

3. 자바 시스템에서는 시스템의 상태를 저장할 때 직렬화를 사용하는 것이 좋다.

 

프로토타입(Prototype) 패턴

어떤 클래스의 인스턴스를 만드는 것이 자원/시간을 많이 잡아먹거나 복잡한 경우에는 프로토타입 패턴을 쓰면 된다.

 

기존 인스턴스를 복사하기만 하면 새로운 인스턴스를 만들 수 있다.(자바에서는 clone()메소드를 이용하거나 역직렬화를 하면 된다.)

이 패턴의 가장 두드러진 특징은 클라이언트 코드에서 어떤 클래스의 인스턴스를 만드는지 전혀 모르는 상태에서도 새로운 인스턴스를 만들 수 있다는 것이다.

 

프로토타입 패턴의 장점

1. 클라이언트에서는 새로운 인스턴스를 만드는 복잡한 과정을 몰라도 된다.

2. 클라이언트에서는 구체적인 형식을 모르더라도 객체를 생성할 수 있다.

3. 상황에 따라서 객체를 새로 생성하는 것보다 객체를 복사하는 것이 더 효율적일 수 있다.

 

프로토타입 패턴의 활용법 및 단점

1. 시스템에서 복잡한 클래스 계층구조에 파묻혀 있는 다양한 형식의 객체 인스턴스를 새로 만들어야 하는 경우에 유용하게 쓰인다.

2. 때때로 객체의 복사본을 만드는 일이 매우 복잡한 경우가 있다는 단점이 있다.

 

비지터(Visitor) 패턴

다양한 객체에 새로운 기능을 추가해야 하는데 캡슐화가 별로 중요하지 않은 경우에 사용하는 패턴이다.

 

비지터 객체는 트래버서(Traverser) 객체하고 함께 돌아간다.

트래서버는 컴포지트 패턴을 쓰는 경우에 복합 객체 내에 속해 있는 모든 객체들에 접근하는 것을 도와주는 역할을 한다.

비지터 객체에서 복합 객체 내의 모든 객체들에 대해서 원하는 작업을 처리할 수 있게 해주는 것이다.

각각의 상태를 모두 가져오고 나면 클라이언트에서는 비지터로 하여금 각 상태들에 대해서 다양한 작업을 처리하도록 요구할 수 있다.

새로운 기능이 필요하게 되더라도 비지터 부분만 고치면 되므로 편하다.

 

비지터 패턴의 장점

1. 구조 자체를 변경시키지 않으면서도 복합 객체 구조에 새로운 기능을 추가할 수 있다.

2. 비교적 손쉽게 새로운 기능을 추가할 수 있다.

3. 비지터에서 수행하는 기능과 관련된 코드를 한 곳에 집중시켜 놓을 수 있다.

 

비지터 패턴의 단점

1. 비지터를 사용하면 복합 클래스의 캡슐화가 깨진다.

2. 컬렉션 내의 모든 항목을 접근하기 위한 트래버서가 있기 때문에 복합 구조를 변경하기가 더 어렵다.

반응형
Comments