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

헤드퍼스트 디자인 패턴 책의 팩토리 패턴(Factory Pattern) 챕터는 70여페이지에 걸쳐 팩토리 패턴의 이름을 가지고 있는 두가지의 패턴을 다루고 있습니다. 팩토리 메서드 패턴과 추상 팩토리 패턴이죠. 그런데 그 전에 팩토리 패턴은 대략 이런것 이라는 식의 워밍업용의 팩토리 패턴을 언급하고 있는데요. 심플 팩토리(Simple Factory) 입니다.

심플 팩토리는 엄밀히 말하면 패턴이라기 보다는 객체지향 프로그래밍을 할때 늘상 사용하게 되는 관용구 같은것이라 패턴으로 취급하지 않는 편입니다. 하지만 뒤에 나올 팩토리 메서드 패턴이나 추상 팩토리 패턴의 기본이 되는 것이라 확실히 짚고 넘어가야 합니다.

심플 팩토리 부분의 코드는 책에 전문이 나와있지 않아 제공되는 자바코드를 직접 컨버팅 하였습니다. 그래서 책의 내용과 약간 다르게 표현된 부분이 있습니다만, 피자는 확실히 주문대로 나옵니다.

(계속 읽기…)

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

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

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

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

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

(계속 읽기…)

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

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

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

(계속 읽기…)

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