13. 디자인패턴 정리

디자인 패턴의 정의

패턴

- 특정 컨텍스트 내에서 주어진 문제에 대한 해결책이다.

컨텍스트

- 패턴이 적용되는 상황을 뜻한다. 반복적으로 일어날 수 있는 상황이어야만 한다.

문제

- 그 컨텍스트 내에서 이루고자 하는 목적을 뜻한다. 하지만 컨텍스트 내에서 생길수 있는 제약조건도 문제에 포함된다.

해결책

- 우리가 찾아내야 하는것. 누구든지 적용해서 일련의 제약조건 내에서 목적을 달성할 수 있는 일반적인 디자인을 뜻한다.

"어떤 컨텍스트 내에서 일련의 제약조건에 의해 영향을 받을 수 있는 문제에 봉착했다면, 그 제약조건 내에서 목적을 달성하기 위한 해결책을 찾아낼 수 있는 디자인을 적용하면된다."

정리

스트래티지 패턴

- 교환 가능한 행동을 캡슐화하고 위임을 통해서 어떤 행동을 할지를 결정한다.

옵저버 패턴

- 상태가 변경되면 다른 객체들한테 연락을 돌릴 수 있게 해준다.

데코레이터 패턴

- 객체를 감싸서 새로운 행동을 제공한다.

팩토리 메서드 패턴

- 생성할 구상 클래스를 서브 클래스에서 결정한다.

추상 팩토리 패턴

- 클라이언트에서 구상 클래스를 지정하지 않으면서도 일군의 객체를 생성할 수 있도록 해준다.

싱글톤 패턴

- 딱 한 객체만 생성되도록 한다.

커맨드 패턴

- 요청을 객체로 감싼다.

어댑터 패턴

- 객체를 감싸서 다른 인터페이스를 제공한다.

퍼사드 패턴

- 일련의 클래스에 대해서 간단한 인터페이스를 제공한다.

템플릿 메서드 패턴

- 알고리즘의 개별 단계를 구현하는 방법을 서브클래스에서 결정한다.

이터레이터  패턴

- 컬렉션이 어떤 식으로 구현되었는지 드러내지 않으면서도 컬렉션 내에 있는 모든 객체에 대해 반복작업을 처리할 수 있게 해준다.

컴포지트 패턴

- 클라이언트에서 객체 컬렉션과 개별 객체를 똑같이 다룰 수 있도록 해준다.

스테이트 패턴

- 상태를 기반으로 한 행동을 캡슐화한 다음 위임을 통해서 필요한 행동을 선택한다.

프록시 패턴

- 객체를 감싸서 그 객체에 대한 접근을 제어한다.

생성관련 패턴

(객체 인스턴스 생성을 위한 패턴으로 클라이언트와 그 클라이언트에서 생성해야 할 객체 인스턴스 사이의 연결을 끊어주는 패턴)

추상팩토리

팩토리 메서드

싱글톤

행동관련패턴

(클래스와 객체들이 상호작용하는 방법 및 역할을 분담하는 방법과 관련된 패턴)

템플릿 메서드

스트래티지

스테이트

이터레이터

커맨드

옵저버

구조관련패턴

(클래스 및 객체들의 구성을 통해서 더 큰 구조를 만들 수 있게 해주는 것과 관련된 패턴)

데코레이터

컴포지트

퍼사드

어댑터

프록시

클래스 패턴

(클래스 사이의 관계가 상속을 통해서 어떤 식으로 정의되는지를 다룬다. 클래스 패턴에서는 컴파일시에 관계가 결정된다)

템플릿 메서드

팩토리 메서드

어댑터

객체패턴

(객체 사이의 관계를 다루며, 객체 사이의 관계는 보통 구성을 통해서 정의된다. 객체 패턴에서는 일반적으로 실행중으로 관계가 생성되기 때문에 더 동적이고 유연하다)

스트래티지

옵저버

데코레이터

추상팩토리

싱글톤

커맨드

퍼사드

이터레이터

컴포지트

스테이트

프록시

KISS Keep it simple (최대한 단순하게)

- 어떻게 하면 단순하게 해결할수 있을까? 하는데 초점을 맞춰야 한다.

디자인 패턴은 만병통치약이 아니다.

- 패턴을 사용할 때는 그 패턴을 사용했을 때 설계한 디자인의 다른 부분에 미칠 수 있는 영향과 결과에 대해 주의깊게 생각해봐야 한다.

패턴 적용시점

- 디자인상의 문제가 적합하다는 확신이 들 경우에 패턴을 도입.

- 만약 더 간단한 해결책이 있다면 패턴을 적용하기 전에 그 해결책을 사용하는 것을 고려해야한다.

- 해결해야 할 문제와 제약조건을 종합적으로 고려해야 한다.

- 패턴 카탈로그의 용도 및 적용 대상 섹션을 보는 것이 좋다.

- 시스템의 어떤 부분이 변경될 것이라고 예측할 수 있는 경우 패턴을 적용할 여지가 있는 것.

리팩토링과 패턴

리팩토링이란

- 코드 구조를 개선하기 위해서 코드를 변경하는 과정을 뜻한다.

리팩토링의 목적은 행동을 변경하는 것이 아니라 구조를 개선하는데 있다.

패턴을 사용하면 구조가 더 나아질지 여부를 검토해 볼 만한 아주 좋은 기회라고 할 수 있다.

예) 조건문이 아주 많이 있는 코드가 있다면 스테이트 패턴을 적용하는 것을 고려해볼만 하다.

팩토리 패턴을 써서 구상 크랠스에 대한 의존성을 말끔하게 정리하는 것도 좋을 수 있다.

디자인 패턴 제거

- 시스템이 점점 복잡해지면서 처음에 기대했던 유연성이 전혀 발휘되지 않게 되는 경우에는 패턴을 과감하게 제거해 버리는게 낫다.

즉 패턴을 사용하지 않는 간단한 해결책이 더 나을 것 같다 싶을 때 패턴을 제거해 버리면 된다.

꼭 필요하지 않는 것을 미리할 필요는 없다.

- 아름다운 아키텍처를 만들고 싶은 마음이 들것이다.

하지만 이런 유혹을 이겨내야 한다. 지금 당장 변화에 대처하기 위한 디자인을 만들어야한다면 패턴을 적용해서 그 변화에 적응 해야 한다.

하지만 꼭 필요하지 않음에도 불구하고 괜히 패턴을 추가하는 것은 피해야 한다.

시스템만 괜시리 복잡해지고 전혀 쓸모가 없게 될수도 있다.

출처 - Head First Design Patterns 저자- 에릭 프리먼, 엘리자베스 프리먼, 케이시 시에라, 버트 베이츠