Observer
?Intent?意圖
??????在對象間定義一個一對多的依賴（dependency）關系，把這些物體分為兩種角色，一種是被觀察者（一），一種是觀察者（多），當被觀察者狀態發生改變的時候，所有依賴于它的觀察者都將得到通知

Varies?變化
??????變化的地方在于，觀察者的數目是隨時可以更新的，并且要保證觀察者們總能得到更新（stay?up-to-date）

Structure?結構

Comments?評論
??????觀察者模式也被稱為“發布者－訂閱者”模式，它的一個主要用途是在document-view結構中（注：在MVC中，主要的兩個模式分別是觀察者模式和Mediator模式），文章認為，觀察者模式的復雜性在于，在實現上選擇Push模型還是Pull模型是一個比較難以抉擇的問題。（注：Push和Pull并不是針對通知而言，兩種模型中都是被觀察者通知觀察者，而非Pull中觀察者去輪詢被觀察者，兩者的區別是，Push模型是指由被觀察者向觀察者發送狀態更改通知的同時發送觀察者相應通知所需的一切被觀察者內部的信息，而Pull模型則是被觀察者只簡單地告訴觀察者狀態發生了改變，觀察者需要再次向被觀察者查詢才可以做下一步的響應動作，兩者所使用的場合是不一樣的，具體而言，Push模型用在它確定觀察者一定會作出響應，因此被觀察者只需一次到位發送全部消息，而Pull模型則考慮到觀察者眾多，未必每一個都需要相同的信息，另外也不是每一個都需要對通知作出響應）

在第三章，介紹了OO相關技術包括UML，其中提到了一個概念：在一個繼承體系中，良好的做法是越往上放越多的Code，而Data則放到越下層（子類or實現類）越好。文章是這樣解釋的：將公共代碼盡可能地放到繼承層次的上方這樣它可以被重用（和數據不同，在繼承的過程中，當子類實例不需要使用的時候，代碼也不會有額外的cost），而數據元素則應該放到越低越好，這樣你不會為不需使用的數據成員付出代價。如下圖：


第四章講的是一個電腦公司的銷售系統，對配件的零售和各種搭配銷售，要求系統能夠統一對待，這里引入了Composite模式，這里不詳述，因為還是比較簡單的。

第五章講的是Decorator模式，首先引入了一個漢堡店的系統，介紹了組合爆炸的設計，并引入Decorator，解決了這種問題。

第六章講的是不同編程語言對模式的實現問題，設計模式和習慣用法（idiom）比較起來，后者是與特定語言相關的，而設計模式則是與語言無關的，這指的是支持OO的語言都支持設計模式，只不過實現起來的復雜程度各有不同，文章舉了一個例子用VB來實現State模式，再用Java來實現，得出上述結論。

第七章第八章我就沒詳細看了，一是覺得這里的圖用的不是標準UML圖，看起來不太順眼，另一個則是內容似乎沒什么特別的。書的最后三分之一都是附錄：代碼。

總的而言，這本書不算一本經典的書，由于在圖書館借的，在還書之前翻了一下。下次打算看的模式書是《Head First Design Pattern》。不過得答辯之后才有時間了。