신입사원 때 당시 팀장님이 매일 디자인 패턴을 공부해오게 한다음 발표를 시키셨다.
인터넷에서 찾아보는 것도 좋지만 검증된 책을 가지고 공부하는게 좋겠다고 하셔서 사내 도서관에서 찾아서 공부했던 책이 바로 헤드퍼스트 디자인패턴이었다. (아직도 기억나는 피자가게 예제...)
디자인 패턴에 대해서 어렴풋이 알고 있었지만 정확히 어떤 것들이 있는지 그때 처음 알게 되었고 이를 계기로 GOF의 디자인 패턴 책을 사서 보게 되었다 (물론 다는 못봤지만....ㅎㅎ)
이렇게 디자인 패턴에 대해 알게 해주었던 헤드퍼스트 디자인패턴이 개정판으로 나왔다는 소식을 페이스북을 통해서 알게되었다.
그래서 개정판은 어떤지 궁금했던 찰나에 개정판을 볼 수 있는 좋은 기회가 생겨 읽게되었다! (Lucky~!!!)

워낙 예전에 이전 버전을 읽었던 지라 개정판 이전 내용들은 기억이 안나지만 그래도 읽으면서 헤드퍼스트 시리지 특유의 구성은 여전했다.
다양한 그림과 말주머니가 가득한 이야기 형식으로 보다 이해하기 쉽게 구성되어 있었다 (이런 부분이 호불호가 있다고 하지만)
대학교 때 교재로 헤드퍼스트 시리즈를 많이 접했던 나에게는 매우 친숙한 구성이다.
또한 헤드퍼스트 디자인패턴은 예제 소스들이 자바로 되어 있어서 자바 개발자인 나에게는 매우 좋았다. (이전 버전에 발표할 때도 해당 예제 소스들을 바탕으로 발표하였었다)
번역체들이 이전 버전과 많이 달라졌다고 하는데 그 부분까지는 잘 기억이 안나지만 개정이 되면서 확실히 더 자연스럽고 깔끔한 문체들로 바뀐 것 같고, 최신 버전의 설명들로 바뀐 부분이 있는 것 같았다.

읽다보니 신입 개발자 시절 발표할 때가 생각나면서 여전히 나에게 디자인 패턴은 헤드퍼스트 디자인패턴인 것 같다ㅎㅎ
그만큼 디자인패턴을 처음 공부하는 입문자에게, 특히 자바 개발자에게 매우 유익한 책이다!

※ 한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.

우리는 무언가 추가하여 꾸밀 때 데코레이션한다는 표현을 많이 쓴다. 그렇다면 데코레이터 패턴도 무언가를 추가해서 꾸미는 패턴일까?

데코레이터 패턴이 무엇인지 한번 알아보자.

데코레이터 패턴이란?

· 객체에 동적으로 새로운 책임을 추가할 수 있게 하는 패턴. (서브클래스를 생성하는 것[상속]보다 융통성 있는 방법을 제공)

※ 장식자 패턴, 랩퍼(Wrapper) 패턴이라고도 부름.

· 무엇인가를 감싸는 객체를 데코레이터(Decorator)라고 부름. 데코레이터는 자신이 둘러싼 요소, 구성요소가 갖는 인터페이스를 자신도 동일하게 제공하므로, 데코레이터의 존재는 이를 사용하는 사용자에게 감춰짐.

즉, 데코레이터는 자신이 둘러싼 구성요소로 전달되는 요청을 중간에 가로채서 해당 구성요소에 전달해줌.

그렇기 때문에 이 전달 과정의 앞뒤에 다른 작업을 추가로 할 수 있음.

데코레이터 패턴이 무엇인지 알아보았지만 아직 와닿지는 않을 것이며, 언제 사용해야 할지 잘 모를 것이다. 그렇다면 이런 데코레이터 패턴은 언제 사용해야 좋을지 알아보자.

언제 데코레이터 패턴은 사용해야 할까?

· 동적으로 또한 투명하게, 다시 말해 다른 객체에 영향을 주지 않고 개개의 객체에 새로운 책임을 추가하기 위해 사용.

· 제거될 수 있는 책임에 대해 사용.

· 실제 상속으로 서브클래스를 계속 만드는 방법이 실질적이지 못할 때 사용. (너무 많은 수의 독립된 확장이 가능할 때 모든 조합을 지원하기 위해 이를 상속으로 해결하면 클래스 수가 폭발적으로 많아지게 됨)

구조

· Component : 동적으로 추가할 서비스를 가질 가능성이 있는 객체들에 대한 인터페이스.

· ConcreteComponent : 추가적인 서비스가 실제로 정의되어야 할 필요가 있는 객체.

· Decorator : Component 객체에 대한 참조자를 관리하면서 Component에 정의된 인터페이스를 만족하도록 인터페이스를 정의.

· ConcreteDecorator : Component에 새롭게 추가할 서비스를 실제로 구현하는 클래스.

데코레이터 패턴의 장점

· 단순한 상속보다 설계의 융통성을 더 많이 증대시킬 수 있음. (상속은 정적으로 새로운 클래스를 추가해야만 추가적인 행동을 정의할 수 있는 방법)

· 클래스 계통의 상부측 클래스에 많은 기능이 누적되는 상황을 피할 수 있음. *필요한 비용만 그때 지불해라!

데코레이터 패턴의 예

· 스트림(Stream)

[참고] GoF의 디자인 패턴