디자인 패턴 책
개인적으로 좋아하는 교수님이 있다. 객체지향 수업을 강의해주신 교수님인데 마지막 수업에서 디자인 패턴 책을 하나 소개 해주셨다. 책 이름은 '헤드 퍼스트 디자인 패턴' 이었다. 디자인 패턴의 정서는 'gof 디자인패턴'이지만 헤드 퍼스트는 그림과 좋은 예시로 처음 디자인 패턴을 읽는 사람이 재미있게 이해할 수 있을 것이라고 하셨다. 방학에 책을 구매했고 전부 읽지는 못했지만 반정도 재미있게 읽었다.
새로운 과제를 진행하다 만난 상황이 이때 읽었던 패턴을 사용하면 좋을 것 같아 다시 책을 폈다. 이 책은 상황을 먼저 주어주고 사람들이 어떤식으로 이 패턴을 적용하게 되었는지 찾아간다. 데코레이터 패턴은 카페 이야기로 시작된다.
카페
카페가 만들어지고 점점 시간이 지나면 이렇게나 메뉴가 늘어난다.
이런 경우 우유를 넣었는지, 모카를 넣었는지 등에 해당하는 boolean타입 필드를 추가하고 각 필드에 해당하는 has, set 메서드를 추가하는 방법으로 구현할 수도 있다. 하지만 음료 가격을 계산하는 행동을 상속하는것은 좋은 방법이 아니다. 나중에 첨가물이 추가될때 이런 메서드들이 수정이 복잡해진다.
OCP
OCP는 Open-Closed Principle 이다. 클래스는 확장에는 열려 있어야 하지만 변경에는 닫혀 있어야 한다는 의미이다. 약간 모순같은 말이다. 하지만 디자인 패턴은 오랬동안 많은 사람들에게서 연구되고 검수받은 작품이다. 따라서 상황에 적절한 디자인 기법을 사용하면 이 원칙을 지키며 이상적은 프로그래밍을 할 수 있다.
패턴을 적용한 카페
위의 방법을 다시 생각해보자. 우유, 모카 등의 첨가물을 장식 이라고 생각하는것이다. 먼저 DarkRoast객체를 가져와 모카 객체로 장식하고, 우유 객체로 장식한다. 그 후 cost 메소드를 호출하면 각 첨가물의 가격을 계산하는 일을 해당 객체에게 위임하는 것이다.
결론적으로 아래의 구조가 된다.
데코레이터 패턴
데코레이터 패턴을 이용하면 객체에 추가 요소를 동적으로 더할 수 있다. 데코레이터를 사용하면 서브클래스를 만들 때보다 훨신 유연하게 그능을 확장할 수 있다.
클래스 다이어그램을 보면 결국 상속으로 문제를 해결한것이 아닌가 라는 생각이 들 수 있지만, 데코레이터 패턴에서는 상속을 사용해서 '형식'을 맞추는것일뿐이다. 맨처음 카페는 상속을 이용해 행동을 물려주는게 아니다.
또한 데코레이터 객체가 자신이 감싸고 있는 객체랑 같은 인터페이스를 가진다. 이는 원래 객체가 들어갈 자리에 데코레이터로 감싼 객체가 들어가야 하기 때문이다. 따라서 한 객체를 여러 개의 데코레이터로 감쌀 수 있다.
마지막으로 데코레이터는 자신이 장식하고 있는 객체에게 어떤 행동을 위임하는 일 말고도 추가 작업을 진행할 수 있다.
결론
이 패턴은 내가 하고자 하는 과제와 잘 맞지 않는것 같다. 왜냐하면 내 과제에서는 원래 객체에 어떤 데코레이터들이 감싸져 있나를 알아야 하는데 그런 로직을 만들기 쉽지 않고 구현한다고 하더라도 원본 패턴의 취지에 어긋나는것같다.
어쩌면 디자인 패턴을 적용하는게 항상 답이 아닌것 같다는 생각이 들었다.
