Something in Ours

觀察者模式一種一對多的關係，讓多個觀察者物件同時監聽某主題物件。物件再狀態發生變化時，會通知觀察者物件，使他門能夠自動更新自己。 動機 將一個系統分割成一系列相互協作的類別有一個很不好的副作用，那就是需要維護相關物件間的一致性。我們不希望為了維持一致性而使各類別緊密耦合，這樣會給維護、擴展和重用都帶來不便。 一個物件的改變需要同時改變其他物件時。且它不知道到底有多少物件有待改變時，應該考慮使用觀察者模式。

範本方法模式是透過把不變行為搬移到超類別，去除子類別中的重複程式法來表現它的優勢 當不變的和可變的行為在方法的子類別實現中混合在一起的時候，不變的行為就會在子類別中重複出現。我們透過範本方法模式把這些行為搬移到單一的地方，這樣就幫助子類別擺脫重複的不變行為的糾纏。

動態地給一個物件加入一些額外的職責，就增加功能來說，裝飾模式比產生子類別更為靈活。

開放-封閉原則(The Open-Closed Principle) 是說軟體實體（類別、模組、函數等）應該可以擴展，但是不可以修改。 依賴倒轉原則 高層模組不應該依賴低層模組。兩個都應該依賴抽象。  抽象不應該依賴細節。細節應該依賴抽象。 Liskov替換原則 一個軟體實體如果使用的是一個父類別的話，那一定適用於其子類別，且它察覺不出父類別物件和子類別物件的區別。亦即，在軟體裡，把父類別都替換成它的子類別，程式的行為沒有變化。簡單說，子類型必須能替換調它們的父類型。 迪米特法則(Law of Demeter)(最少知識原則) 如果兩個類別不必彼此直接通信，那麼這兩個類別就不應當發生直接的相互作用。如果其中一個類別需要調用另一個類別的某一個方法的話，可透過第三者轉發這個調用。 合成／聚合複用原則 儘量使用合成／聚合，儘量不要使用類別繼承。 聚合表示一種弱的「擁有」關係，表現的是A物件可以包含B物件，但B物件不是A物件的一部分 合成則是一種強的「擁有」關係，表現了嚴格的部份和整體的關係，部份和整體的生命週期一樣 敏捷開發原則 不要為程式碼加上基於猜測的、實際不需要的功能。 如果不清楚一個系統是否需要命令模式，就不要急著去實現它。事實上，在需要的時候透過重構實現此模式並不困難，只有在真正需要如取消/恢復操作等功能時，把原來的程式碼重構為命令模式才有意義。

它定義了演算法家族，分別封裝起來，讓它們之間可以互相替換，此模式讓演算法的變化，不會影響到使用演算法的客戶。 策略模式是一種定義一系列演算法的方法，從概念上來看，所有這些演算法完成的都是相同的工作，只是實現不同，它可以以相同的方式調用所有的演算法，減少各演算法類別與使用演算法類別之間的耦合。 策略模式的Strategy類別層次為Context定義了一系列的可供複用的演算法或行為。繼承有助於析取出這些演算法中的公共功能。 策略模式是用來封裝演算法的，但在實踐中，我們發現可以用它來封裝幾乎任何類型的規則，只要在分析過程中聽到需要在不同時間應用不同的業務規則，就可以考慮使用策略模式處理這種變化的可能性。