세계의끝과 플래시 원더랜드

Head First Design Pattern 의 제 3 장 내용인 데코레이터 패턴(Decorator Pattern) 입니다.

먼저 데코레이터 패턴에 대한 정의 입니다.

“데코레이터 패턴에서는 객체에 추가적인 요건을 동적으로 첨가한다. 데코레이터는 서브클래스를 만드는 것을 통해서 기능을 유연하게 확장할 수 있는 방법을 제공한다.”

본문에 예로 든 상황은 커피체인점에서 커피와 첨가물에 대한 가격을 계산하는 프로그램을 만드는 것입니다. 우리나라의 커피체인점은 인기있는 메뉴를 몇개 정하여 정해진 포맷으로 만들어 내는 형식을 가지고 있죠. 모카 카라멜 마끼아또 같이 이미 휘핑크림이 들어가 있고, 카라멜시럽을 뿌리고 하는 등의 정해진 모양을 만들어 냅니다.

그러나 역시 미국에서는 영화에서 보는것과 같이 종류가 다른 커피에 역시 각기 다른 첨가물을 직접 선택할 수 있게 함으로서 소비자의 취향을 중시하는 분위기가 있는 것입니다. 그래서 예로 든 커피체인점의 첨가물을 위한 프로그래밍은 데코레이션 패턴을 설명하기 위한 매우 적절한 예로 보입니다. 정말 데코레이션 하잖아요.

(계속 읽기…)

이 포스트는 Head First Design Pattern : Observer Pattern 옵저버 패턴을 액션스크립트로 컨버팅 의 마지막 부분에서 언급했던 잘못된 패턴 구현에 대한 코드 수정을 위한 포스트 입니다.

이 문제의 발단은 옵저버 구상 클래스에서 주제인 weatherData 객체를 레퍼런스로 저장하는데서 비롯되었습니다. 주제가 어떤 녀석인지 옵저버에 저장하는 순간 이 옵저버는 더이상 옵저버가 아니고 주제에 직접적으로 관여하는 입장이 되어버립니다.

아래 코드 부분은 수정된 옵저버 구상 클래스 입니다. 현재 주석처리 되어있는 생성자 부분에서 주제인 weatherData 를 인스턴스 변수로 저장할 뿐만 아니라, 심지어 옵저버 스스로 옵저버가 되기를 희망하며 주제의 메소드를 직접 호출하며 옵저버 등록을 시도하게 되어버렸던 것입니다. 이 결과, 주제는 info를 옵저버 들에게 돌려야 하므로 옵저버들이 누군지 당연히 원래부터 알고 있고^[01] 옵저버 역시 주제가 누군지 알고 있을 뿐더러 주제의 메소드를 호출하는 형태를 띄게 되면서, 객체지향 언어에서 지양(止揚)해야 할, 객체간 강한 결합을 해버리게 됩니다.^[02] 

(계속 읽기…)

1. 주제 객체 내부에 배열로 옵저버 리스트를 관리하고 있었습니다. [↑]
2. OOP 의 원칙 중 클래스 사이의 결합도는 약하게, 하나의 클래스 안에서의 응집도는 강하게 라는 원칙이 있음은 주지의 사실입니다. [↑]

Head First Design Pattern 의 제 2 장 내용인 옵저버 패턴(Observer Pattern) 으로 들어가 보겠습니다. 역시 이번에도 자바 코드를 액션스크립트로 컨버팅 하였습니다.

다음은 책 본문에 있는 옵저버 패턴에 대한 설명입니다.

“옵저버 패턴 – 한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체들한테 연락이 가고 자동으로내용이 갱신되는 방식으로 일대다(one-to-many) 의존성을 정의합니다.

사실 위의 정의만 보고는 뭐가 뭔지 알쏭달쏭한데요, 차근차근 풀어나가보겠습니다.
(계속 읽기…)