헤드퍼스트 디자인 패턴 간략정리

출처

: http://wiki.gurubee.net/pages/viewpage.action?pageId=1507398 ( 좋은 자료 감사합니다. ( ㅡ ㅡ ) )

상속 (Inheritance)

구성 (Composite), 컴포짓

일맥상통하는 개념은 느슨한 결합을 위해서는 추상메서드, 혹은 같은 맥락으로 인터페이스를 잘 활용하는 것이다. 컴퓨터는 정확한 명령어에 의해서 돌아가는데 이런 명령어를 추상화시킨다는 것은 확장성을 높일 수 있는 근간이 된다.

"변화하는것 과 변화하지 않는것을 분리하는것이 패턴의 시작이다." 가장기본적인 기능 = 변화 하지 않는것 꾸며주는 기능(계속 추가되는 기능 혹은 추가 될수 있는 기능) = 변화하는것

패턴 이란 특정 컨텍스트 내에서 주어진 문제 에 대한 해결책 이다. 컨텍스트(context)란 패턴이 적용되는 상황을 뜻합니다. 반복적으로 일어 날 수 있는 상황이어야만 합니다. 문제(problem)란 컨텍스트 내에서 이루고자 하는 목적을 뜻합니다. 또한 컨텍스트 내에서 생길 수 있는 제약조건도 문제에 포함됩니다. 해결책(solution)이 바로 우리가 찾아내야 하는 것입니다. 누구든지 적용해서 일련의 제약조건 내에서 목적을 달성할 수 있는 일반적인 디자인을 뜻합니다.

패턴으로 생각하기

최대한 단순하게(KISS-Keep it Simple) 가장 중요한건 최대한 단순한 방법으로 문제를 해결해야 한다는 점이다. 어떻게 패턴을 적용 할 수 있는가? 보다는 어떻게 하면 단순하게 해결할 수 있을까에 초점을 맞춰야 한다. 디자인패턴은 만병 통치약이 아니다. 패턴은 반복적으로 발생하는 문제에 대한 일반적인 해결책이고, 수 많은 개발자들에 의해서 오랫동안 검증받은 해결책이다. 하지만 패턴을 사용 했을 때 설계한 디자인의 다른 부분에 미칠 수 있는 영향과 결과에 대해 주의 깊게 생각해 봐야 한다. 다음과 같은 경우에 패턴이 필요하다. 디자인을 할 때, 지금 디자인상의 문제에 적합하다는 확신이 들 경우에 패턴을 도입해야 한다. 만약 더 간단한 해결책이 있다면 패턴을 적용하기 전에 그 해결책을 사용하는 것을 고려해야 한다. 패턴을 도입하는 것은 디자인 단계에서만 고려해야 하는 일이 아니라, 리팩토링 할 때도 패턴을 고려해야 한다. 리팩토링과 패턴 리팩토링(refactoring)이란 코드 구조를 개선하기 위해서 코드를 변경하는 과정을 말한다. 리팩토링의 목적은 행동을 변경하는 것이 아니라 구조를 개선하는 데 있다. 패턴을 이용하면 구조를 좀 더 효율적으로 개선 할 수 있다. 꼭 필요하지 않은 것은 빼 버립시다. 상황에 따라서는 디자인 패턴을 제거하는 것에 대해서 생각해 봐야 한다. 시스템이 점점 복잡해 지면서 처음에 기대했던 유연성이 전혀 발휘되지 않는 경우 패턴을 과감히 제거하는 것이 낫다. 꼭 필요하지 않은 것을 미리 할 필요는 없다. 꼭 필요하지 않음에도 불구하고 괜히 패턴을 추가하는 것은 피해야 한다.

1. 스트레트지 패턴

: 교환 가능한 행동을 캡슐화하고 위임(Delegate)을 통해서 어떤 행동을 사용할지 결정한다. 스프링에서 생각해보면, 서비스 인터페이스에 @Autowired로 DI를 통해 사용한 것과 일치한다. 서비스는 인터페이스를 통해서 로직을 구성할 수 있으면 실질적인 구현체는 몰라도 된다. 스프링의 어플리케이션 컨텍스트가 구현체를 주입해주기 때문이다. 이를 통해서 객체간 결합이 느슨해질 수 있다.

2. 옵저버 패턴

: 1대 다 관계

: 일반적으로 Listener를 생각하면 된다. @Autowired로 여러개의 구현체가 등록된 컬렉션을 호출한다. 일반적인 서비스 로직이 호출된 뒤에 모든 리스너를 호출하는 형식으로 보인다.

3. 데코레이터 패턴

: 상속을 통해 확장을 할 수도 있지만, 디자인 유연성 면에서는 별로 좋지 않다.

: 기존 코드를 수정하지 않고도 행동을 확장하는 방법이 필요하다.

: 구성과 위임을 통해서 실행중에 새로운 행동을 추가할 수 있다.

: 상속대신 데코레이터 패턴을 통해서 행동을 확장 할 수 있다.

: 데코레이터 패턴에서는 구상 구성요소를 감싸주는 데코레이터들을 사용한다. 

: 데코레이터의 수퍼클래스는 자신이 장식하고 있는 객체의 수퍼클래스와 같다.

: 데코레이터 패턴을 사용하면 자질한 객체들이 많이 추가될 수 있고, 데코레이터를 너무 많이 사용하면 코드가 필요 이상으로 복잡해 질 수 있다.

4. 팩토리 패턴

: 팩토리 패턴, 팩토리 메소드 패턴, 추상 팩토리 패턴이 존재한다.

: 팩토리를 쓰면 객체 생성을 캡슐화 할 수 있다.

: 간단한 팩토리는 엄밀하게 말해 디자인 패턴은 아니지만, 클라이언트와 구상 클래스를 분리시키기 위한 간단한 기법으로 활용할 수 있다.

: 팩토리 메소드 패턴에서는 상속을 활용한다. 객체 생성이 서브클래스에게 위임된다. 서브클래스에서는 팩토리 메소드를 구현하여 객체를 생산한다.

: 추상 팩토리 패턴에서는 객체 구성을 활용한다. 객체 생성이 팩토리 인터페이스에서 선언한 메소드들에서 구현된다.

: 모든 팩토리 패턴에서는 애플리케이션의 구상 클래스에 대한 의존성을 줄여줌으로써 느슨한 결합을 도와준다.

: 팩토리 메소드 패턴에서는 어떤 클래스에서 인스턴스를 만드는 일을 서브클래스한테 넘긴다.

: 추상 팩토리 패턴은 구상 클래스에 직접 의존하지 않고도 서로 관련된 객체들로 이루어진 제품군을 만들기 위한 용도로 쓰인다.

: 의존성 뒤집기 원칙을 따르면 구상 형식에 대한 의존을 피하고 추상화를 지향할 수 있다.

: 팩토리는 구상 클래스가 아닌 추상 클래스/인터페이스에 맞춰서 코딩할 수 있게 해 주는 강력한 기법이다.

5. 싱글톤 패턴

6. 커맨드 패턴

: 커맨드 패턴 사용시 작업을 요청한 쪽과 그 작업을 처리한쪽을 분리 시킬수 있다.

: Command 를 인터페이스화 시켜서 커맨드를 요청 시 추상화된 Command 메소드를 호출하는 방식

7. 어댑터 패턴

: 한 클래스의 인터페이스를 클라이언트에서 사용하고자 하는 다른 인터페이스로 변환합니다.

: 어댑터를 이용하면 인터페이스 호환성 문제 때문에 같이 쓸 수 없는 클래스들을 연결해서 쓸 수 있습니다.

: DTO는 Data Transfer Object로 데이터 이동에 사용되는 오브젝트이다. 이 오브젝트에 기능이 추가되는 것은 지향해야 한다. 다른 모듈에서 프로젝트에 DTO를 사용하고 싶은 경우 의존성을 줄이기 위해서 인터페이스를 사용하는데, DTO의 정의상 기능이 추가되는 것은 지향해야 함으로  Wrapper 클래스를 어댑터 패턴을 사용하여 기능을 제공하도록 하고 있다.

8. 퍼사드 패턴

: 필요한 메소드만을 외부로 노출시켜 로직의 복잡도를 낮춘다.

: 객체지향 프로그램에서 자주 사용한다.

9. 템플릿 메소드 패턴

: 메소드에서 알고리즘의 골격 정의

: 알고리즘의 여러 단계(method) 중 일부는 SubClass에서 구현 가능

: 알고리즘의 구조는 그대로 유지하면서 SubClass에서 특정 단계를 재정의할 수 있다.

: 알고리즘의 단계를 정의하는 데 일부 단계는 서브클래스에서 구현하도록 할 수 있다.

: 후크(hook)는 아무 일도 하지 않거나 기본 행동을 정의하는 메소드로 서브 클래스에서 오버라이드 할 수 있다.

: 서브 클래스에서 함부로 알고리즘을 고치지 못하게 할려면 final로 선언해라

10. 이터레이터 패턴

: 컬렉션의 구현을 드러내지 않으면서도 컬렉션에 있는 모든 객체들에 대해 반복작업을 할 수 있다.

11. 컴포짓 패턴

: 클라이언트에서 객체 컬렉션과 개별 객체를 똑같은 식으로 처리할 수 있다.

12. 스테이트 패턴

: 스테이트 패턴을 이용하면 내부 상태를 바탕으로 서로 다른 행동을 할 수 있다.

: 각 상태를 클래스를 이용하여 표현

: Context 객체에서는 현재 상태에게 행동을 위임한다.

: 각 상태를 클래스로 캡슐화함으로써 나중에 변경해야하는 내용을 국지화시킬 수 있다.

: 스테이트 패턴과 스트래티지 패턴의 클래스 다이어그램은 똑같다.

: 스트래티지 패턴에서는 행동 또는 알고리즘을 Context클래스를 만들 때 설정한다.

: 상태 전환은 State 클래스에 의해 제어할 수 있고 Context클래스에 의해서 제어할 수도 있다.

: 클래스 개수가 늘어나는 단점이 있다.

: State 클래스를 여러 Context객체의 인스턴스에서 공유하도록 디자인 가능하다.

13. 프록시 패턴

: 일반적으로 프록시는 다른 무언가와 이어지는 인터페이스의 역할을 하는 클래스이다. 

14. 컴파운드 패턴

: 2개 이상의 디자인 패턴을 조합한 패턴