[13주차] - 실전 디자인 패턴 & 기타 패턴

[GusersMissin]

13장 실전 디자인 패턴

패턴(Pattern)

• 특정 컨텍스트 내에서 주어진 문제의 해결법
• 다른 개발자와 효과적인 토론을 위하여 이름이 필요함

컨텍스트(Context)

• 패턴이 적용되는 상황
• 반복적으로 일어날 수 있는 상황

문제(Problem)

• 컨텍스트 내에서 이뤄야 하는 목표
• 제약조건도 포함

해결책(solution)

• �목표를 이룰 수 있는 일반적인 디자인

디자인 패턴의 분류

용도에 따른 3가지 분류

• 생성 패턴(Creational Pattern): 객체 인스턴스를 생성하는 패턴
  예: 싱글턴, 추상 팩토리, 팩토리 메소드, 빌더, 프로토 타입
• 행동 패턴(Behavioral Pattern): 클래스와 객체들이 상호작용하는 방법과 역하을 분담하는 방법을 다루는 패턴
  예: 템플릿 메소드, 싱글턴, 반복자, 옵저버, 상태, 전략, 중재자, 비지터, 메멘토, 인터프리터, 역할 변경
• 구조 패턴(Structural Pattern): 클래스와 객체를 더 큰 구조로 만들 수 있게 구상을 사용하는 패턴
  예: 데코레이터, 컴포지트, 프록시, 퍼사드, 어댑터, 브리지, 플레이웨이트

대상(클래스, 객체)에 따른 분류

• 클래스 패턴(Class Pattern): 클래스 사이의 관계가 상속으로 어떻게 정으되는지를 다룸
  예: 템플릿 메소드, 팩토리 메소드, 어댑터, 인터프리터
• 객체 패턴(Object Patterns): 객체 사이의 관계를 다루며, 객체 사이의 관계는 보통 구성으로 정의 됨
  예: 컴포지트, 데코레이터, 커맨드, 반복자, 퍼사드 ... (클래스 패턴에 비해 훨씬 많음)

언제 패턴을 적용하는가?

• 패턴을 적용시킴으로서 문제를 단순하게 해결 될 수 있으며, 패턴 적용에 의해 시스템의 어떤 부분이 어떻게 변할지 예측 가능한 경우
• 최대한 단순 방법(KISS, Keept it Simple)로 문제를 해결해야함
• "이 문제에 어떻게 패턴을 적용 할 수 있을까" 보다는 "어떻게 하면 단순하게 해결 할 수 있을까에 집중"
• 디자인 단계에서 뿐만 아니라 리팩터링 시에도 도입을 고려 할 수 있음

리팩터링:코드를 변경해서 코드 구조를 개선하는 과정

언제 패턴을 제거하는가?

• 패턴을 적용하는것 보다 간단한 해결책이 더 나은 경우
  예: 시스템이 점점 복잡해지면서 처음에 기대했던 유연성이 전혀 발휘되지 못하는 경우

새로운 디자인 패턴 작성

• 실전 문제 해결에 3번 이상 적용 되어야함(3의 규칙)

작성 과정

1. 기존의 패턴 파악
2. 경험을 토대로 반복적인 문제를 해결 할 수 있는 새로운 디자인이 되도록 고려(적용 범위가 너무 좁아지지 않도록 주의)
3. 다른 사람들이 적용해 보고 피드백을 제공 할 수 있도록 문서화
4. 다른 사람들이 피드백을 반영시켜 재 검증 하는 과정을 반복

디자인 패턴의 전문 용어

• 전문용어를 사용하면 설명을 단축시켜 의사소통에 도움이됨

용어를 공유하는 5가지 방법

1. 디자인 회의에서 디자인 패턴을 사용하면 디자인 자체에 더 많은 시간을 할애할 수 있음
2. 다른 개발자들과 토론할 때 다른 개발자들이 새로운 패턴을 배울 때 도움이 되고 커뮤니티를 구축하는데 도움이 됨
3. 아키텍처 문서에 용어를 사용하면 설명하는 분량을 줄일 수 있음
4. 클래스와 메소드의 이름을 만들 때나 코드 주석에 사용중인 패턴을 드러날 경우 다른 개발자들이 무엇을 어떻게 구현했는지 빠르게 이해 할 수 있음
5. 개발자 모임에서 자신이 사용중인 패턴을 다른 사람들에게 소개 함으로 커뮤니티 구축에 도움이 됨

디자인 패턴 카탈로그

교재

• GOF의 디자인 패턴 - 모든 기초 패턴을 찾을 수 있음
• The Timeless way of Building
• A Pattern Language

웹사이트

• 포틀랜드 패턴 리포지토리(The Portlang Patterns Repository)
• 힐사이드 그룹(The hillside Group)
• 오라일리 온라인 학습(O'Reilly Online Learning)

콘퍼런스 및 워크숍

• Pattern Language of Programs(PLoP)
• ACM Conference on Object-Oriented System, Languages and Applications(OOPLSA)

안티패턴(Anti-Pattern)

• 어떤 문제의 나쁜 해결책에 이르는 길
• 어떤 이유로 나쁜 해결책에 유혹되는지를 알려 줌
• 장기적인 관점에서 그 해결책이 나쁜 이유를 알려 줌
• 좋은 해결책을 만들 때 적용할 수 있는 다른 패턴을 제안해 줌

---

14장 기타 패턴

브리지 패턴

• 추상화 된 부분과 구현 부분을 서로 다른 클래스 계층구조로 분리

활용법

• 여러 플랫폼에서 사용해야 할 경우 그래픽스와 윈도우 처리 시스템에 유용하게 쓰임
• 인터페이스와 실제 구현 부분을 다른 방식으로 변경해야할 때 유용하게 쓰임

장점

• 구현과 인터페이스를 완전히 결합하지 않았기 때문에 구현과 추성화 부분을 분리 할 수 있음
• 추상화 된 부분과 실제 구현 부분을 독립적으로 확장할 수 있음
• 구상 클래스가 바뀌어도 클라이언트에는 영향을 끼치지 않음

단점

• 디자인이 복잡해짐

빌더 패턴

• 복합 객체 생성 작업을 별도의 객체로 캡슐화해서 컬렉션의 내부 구조를 클라이언트로부터 보호 함

활용법

• 복합 객체 구조를 구축하는 용도로 쓰임

장점

• 복합 객체 생성 과정을 캡슐화 함
• 여러 단계와 다양한 절차를 거쳐 객체를 만들 수 있음
• 제품의 내부 구조를 클라이언트로부터 보호할 수 있음
• 제품을 구현한 코드를 쉽게 바꿀 수 있음

단점

• 객체를 만들 때 클라이언트에 관해 더 많이 알아야 함

책임 연쇄 패턴

• 주어진 요청을 검토하는 객체 사슬을 생성
• 사슬에 속해 있는 각 객체는 자기가 받은 요청을 검사해서 직접 처리하거나 사슬에 들어있는 다른 객체에게 넘김

활용법

• 1개의 요청을 2개 이상의 객체에서 처리해야 할 때 사용
• 윈도우 시스템에서 마우스 클릭과 키보드 이벤트를 처리할 때 흔히 쓰임

장점

• 요청을 보낸 쪽과 받는 쪽을 분리 할 수 있음
• 객체는 사슬의 구조를 몰라도 됨으로 객체를 단순하게 만들 수 있음
• 사슬에 들어가는 객체를 바꾸거나 순서를 바꿈으로 역할을 동적으로 추가하거나 제거할 수 있음

단점

• 요청이 반드시 수행된다는 보장이 없음
• 실행 시 과정을 살펴보거나 디버깅하기가 힘듬

플라이웨이트 패턴

• Tree의 인스턴스는 하나만 만들고 모든 나무의 상태를 클라이언트 객체가 관리

활용법

• 인스턴스 하나로 여러 개의 가상 인스턴스를 제공할 때 사용
• 어떤 클래스의 인스턴스가 아주 많이 필요하지만 모두 똑같은 방식으로 제어해야 할 때 유용하게 쓰임

장점

• 실행 시에 객체 인스턴스의 개수를 줄여 메모리를 절약 할 수 있음
• 여러 가상객체의 상태를 한곳에 모아 둘 수 있음

단점

• 특정 인스턴스만 다른 인스턴스와 다르게 행동하게 할 수 없음

인터프리터 패턴

• 문법과 구문을 번역하는 인터프리터 클래스를 기반으로 간단한 언어를 정의
• 언어에 속하는 규칙을 나타내는 클래스를 사용해서 언어를 표현

활용법

• 간단한 언어를 구현 할 떄 유용하게 쓰임
• 효율보다는 단순하고 간단한 문법을 만드는 것이 중요할 때 유용함
• 스크립트 언어와 프로그래밍 언어 모두 쓸 수 있음

장점

• 문법을 클래스로 표현해서 쉽게 언어를 구현할 수 있음
• 문법이 클래스로 표현되므로 언어를 쉽게 변경하거나 확장 할 수 있음
• 클래스 구조에 메소드만 추가하면 프로그램을 해석하는 기본 기능 외에 예쁘게 출력하는 기능이나 더 나은 프로그램 확인 기능 같은 새로운 기능을 추가 할 수 있음

단점

• 문법 규칙의 개수가 많아지면 아주 복잡해짐

중재자 패턴

• 상태가 바뀔 때 마다 중재자에게 알려줌
• 중재자에게 보낸 요청에 응답함

활용법

• 서로 관련된 객체 사이의 복잡한 통신과 제어를 한곳으로 집중하고 싶을 때 사용
• 서로 연관된 GUI 구성 요소를 관리하는 용도로 쓰임

장점

• 시스템과 객체를 분리함으로써 재사용성을 획기적으로 향상시킴
• 제어 로직을 한 군데 모아놔서 관리하기 쉬움
• 시스템에 들어오는 객체 사이에 오가는 메시지를 단순화 시킬 수 있음

단점

• 디자인을 잘 하지 못하면 중재자 객체가 너무 복잡해질 수 있음

메멘토 패턴

• 시스템에서 핵심적인 기능을 담당하는 객체의 상태 저장
• 핵심적인 객체의 캡슐화 유지

활용법

• 메멘토 객체를 써서 상태를 저장함
• 시스템의 상태를 저장하여 이전 상태로 복구해야 할 때 사용할 수 있음

장점

• 저장도니 상태를 핵심 객체와는 다른 별도의 객체에 보관할 수 있음
• 핵심 객체의 데이터를 계속해서 캡슐화된 상태로 유지할 수 있음
• 복구 기능을 구현하기 쉬움

단점

• 상태를 저장하고 복구하는데 시간이 오래 걸릴 수 있음

프로토타입 패턴

• 기존 인스턴스를 복사하기만 해도 새로운 인스턴스를 만들 수 있음
• 클라이언트 코드에서 어떤 클래스의 인스턴스르 만드는지 전혀 모르는 상태에서도 새로운 인스턴스를 만들 수 있음

활용법

• 시스템에서 복잡한 클래스 계층구조에서 파묻혀 있는 다양한 형식의 객체 인스턴스를 새로 만들어야 할 때 유용함

장점

• 클라이언트는 새로운 인스턴스를 만드는 과정을 몰라도 됨
• 클라이언트는 구체적인 형식을 몰라도 객체를 생성할 수 있음
• 상황에 따라서 객체를 새로 생성하는것 보다 객체를 복사하는것이 더 효율적임

단점

• 객체의 복사본을 만드는 일이 복잡할 수 있음

비지터 패턴

• 복합 객체 내의 모든 객체를 대상으로 원하는 작업을 처리
• 트래버서 객체와 함께 돌아감(복합 객체 내에 속행 있는 모든 객체에 접근하는 일을 도와주는 역할)

활용법

• 다양한 객체에 새로운 기능을 추가해야 하는데 캡슐화가 별로 중요하지 않을 때 사용

장점

• 구조를 변경하지 않으면서도 복합 객체 구조에 새로운 기능을 추가 할 수 있음
• 손쉽게 새로운 기능을 추가할 수 있음
• 비지터가 수행하는 기능과 관련된 코드를 한곳에 모아둘 수 있음

단점

• 복합 클래스의 캡슈로하가 깨짐
• 컬렉션 내의 모든 항목에 접근하는 트래버서가 있으므로 복합구조를 변경하기 더 어려워짐