Tagged

Head First Design Pattern

A collection of 7 posts

Head First Design Pattern

2장 Observer Pattern(계속)

기상 스테이션 복잡해 보일 수도 있지만 매우 간단한 class diageam입니다. 각각의 display들이 Display interface를 구현하도록 추가한 것만 빼면 기본적인 observer패턴의 모습과 같습니다. WeatherData class에는 observer들을 등록, 삭제할 List를 가지고 있어야 합니다. 그래야 나중에 상태가 바뀌었을 때(measurementsChanged()가 호출됐을 때) notifyObservers() 메소드에서 자신의 정보를 원하는 옵저버들에게 정보를 줄 수 있겠죠.
Head First Design Pattern

2장 Observer Pattern(계속)

신문을 구독하는 방법과 동일 합니다. 책에는 출판사 + 구독자 = 옵저버 패턴 이라고 큼지막하게 쓰여있네요. 출판사는 주제(subject)로 부르고 구독자는 옵저버(observer)라고 부르도록 하겠습니다. 앞에서 본 예제에 적용하면 weatherData 객체가 subject 그리고 각종 display장치들이 옵져버에 해당합니다. 위 기본 설정을 중간에 잊어버리시면 앞으로 진행되는 설명을 이해하는데 막대한 지장이 있을 것입니다. 주제와
Head First Design Pattern

2장 Observer Pattern

엠파스 블러그에서 가져옵니다. 너무도 많이 들어본 이름.. 옵져버 스타크래프트의 럴커나 다템 같은 안보이것 까지 볼 수 있는 유닛이다. 게임 중 후반에 이르러 옵져버가 있으면 상대방이 어디에 무슨 병력을 얼만큼 갖다 놨는지 무슨 건물을 짓고 있는지 훤히 알 수 있기 때문에 매우 중요한 유닛이다. 사설은 이만 하고 본론으로 들어갑니다. 책의 첫
design pattern

1장 Strategy Pattern (끝)

최종적으로 위와 같은 다이어그램이 완성됩니다. 상속으로 시작했던 디자인이 composition(구성)을 사용함으로써 결말이 났군요. 이로써 다음과 같은 디자인 원칙을 배울 수 있습니다. 디자인 원칙3 상속보다는 구성을 활용한다. 위에서 했던 행동들이 하나의 디자인 패턴으로 정립되어 있었습니다. 바로 Strategy pattern 이라는 것으로 써 정의는 다음과 같습니다. Strategy Pattern에서는 알고리즘군을 정의하고 각각을 캡슐화하여
design pattern

1장 Strategy Pattern(계속)

이전 글에서 발생했던 문제를 해결하기 위해서 interface를 사용하여 날아다닐 수 있는 오리와 소리낼 수 있는 오리로 구분하였습니다. 날아 다니거나 소리 낼 수 있는 오리들은 해당 interface를 구현해야 하며 따라서 fly나 quack과 같은 method들을 구현해 주어야 합니다. 만약에 이런 상황에서 오리의 소리가 공통적으로 바뀐다면 어떻게 해야할까요? 아마 Quackable을 구현한 모든 class들을
design pattern

1장 Strategy Pattern

위 다이어그램을 보면 Duck class를 상속을 이용하여 재사용 하고 있습니다. 필요한 부분( 여기서는 display() )만 overriding 해주면 되기 때문에 상당히 편리해 보입니다. 기본 기능으로 오리가 날수 있도록 하고 싶을 때… 위와 같이 상위 class에 추가하기만 하면 모든 하위 class들에 일일히 추가할 필요가 없기때문에 편리해 보입니다. 하지만… 날지 못하는