物件導向設計模式的核心法則

1. 單一職責

就一個類而言，應該僅有一個引起它變化的原因。
如果一個類承擔的職責過多，就等於把這些職責耦合在一起，一個職責的變化可能會削弱或者抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當變化發生時，設計會遭到意想不到的破壞。
軟體設計真正要做的許多內容，就是發現職責並把那些職責互相分離。如果你多於一個動機去改變一個類，那麼這個類就具有多於一個的職責。

2. 開放封閉

軟體實體（類，模組，函數等）應該可以擴充，但是不可修改。也就是說，對於擴充是開放的，對於更改是封閉的。
如此設計，面對需求的改變可以保持相對的穩定，從而使系統可以在第一個版本以後不斷的推出新的版本。
無論模組是多麼的'封閉'，都會存在一些無法對之封閉的變化。既然不可能完全封閉，設計人員必須對於他設計的模組應該對哪種變化封閉做出選擇。他必須先猜測出最有可能發生的變化種類，然後構造抽象來隔離那些變化。
等到變化發生時立即採取行動。

在我們最初編寫代碼時，假設變化不會發生。當變化發生時，我們就建立抽象來隔離以後發生的同類變化。
面對需求，對程式的改動是通過增加新代碼進行的，而不是更改現有的代碼。
我們希望的是在開發工作展開不久就知道可能發生的變化。查明可能發生的變化所等待的時間越長，要建立正確的抽象就越困難。
開放-封閉原則是物件導向設計的核心所在。遵循這個原則可以帶來物件導向技術所聲稱的巨大好處，也就是可維護、可擴充、可複用、靈活性好。開發人員應該僅對程式中呈現出頻繁變化的那些部分做出抽象，然而，對於應用程式中的每個部分都可以的進行抽象同樣不是一個好主意。拒絕不成熟的抽象和抽象本身一樣重要。

3. 依賴倒轉

高層模組不應該依賴底層模組。兩個都應該依賴抽象。
抽象不應該依賴細節，細節應該依賴抽象。
抽象不應該依賴細節，細節應該依賴於抽象，針對介面編程，不要對實現編程。
依賴倒轉其實可以說是物件導向設計的標誌，用哪種語言來寫程式並不重要，如果編寫時考慮的都是如何針對抽象編程而不是針對細節編程， 即程式中所有的依賴關係都終止於抽象類別或者介面，那就是物件導向的設計，反之那就是過程化的設計了。

4. 裡氏代換

一個軟體實體如果使用的是一個父類的話，那麼一定適用於其子類，而且察覺不出父類對象與子類對象的區別。也就是說，在軟體裡面，把父類都替換成它的子類，程式的行為沒有變化。
子類型必須能用替換掉它們的父類型。
只有當子類可以替換掉父類，軟體單位的功能不受到影響時，父類才能真正被複用，而子類也能夠在父類的基礎上增加新的行為。

5. 合成/彙總複用

盡量使用合成/彙總，盡量不要使用類繼承。
優先使用對象的合成/彙總將有助於你保持每個類被封裝並被集中在單個任務上，這樣累和類繼承層次會保持較小的規模，並且不大可能增長為不可控制的龐然大物。

6. 迪米特法則

如果兩個類不必彼此直接通訊，那麼著兩個類就不應當發生直接的相互作用。如果其中一個類需要調用另一個類的某一個方法的話，可以通過第三者轉寄這個調用。
在類的結構設計上，每一個類都應當盡量降低成員的存取權限，也就是說，一個類封裝好自己的private狀態，不需要讓別的類知道的欄位或行為就不要公開。
迪米特法則其根本思想是強調了類之間的松耦合。

類之間的耦合越弱，越有利於複用，一個處在弱耦合的類被修改，不會對有關係的類造成波及。

輔助資料：

常用建立型設計模式（其他類型模式就不提了，自己看書）

建立型模式隱藏了這些類的執行個體是如何被建立和放在一起，整個系統關於這些對象所知道的是由抽象類別所定義的介面。這樣，建立型模式在建立了什麼、誰建立它=它是怎麼被建立的，以及何時建立這些方面提供了很大的靈活性。

1. Factory 方法模式（Factory Method）

定義一個用於建立對象的介面，讓子類決定執行個體化哪一個類，原廠模式使一個類的執行個體化延遲到其子類。
建立型模式抽象了執行個體化的過程，它們協助一個系統獨立於如何建立、組合和表示它的那些對象。建立型模式都會將關於該系統使用哪些具體的類的資訊封裝起來。允許客戶用結構和功能差別個很大的'產品'對象配置一個系統。配置可以是靜態，即在編譯時間制定，也可以是動態，就是運行時再指定。
通常設計應該是從Factory 方法開始，當設計者發現需要更大的靈活性時，設計便會向其他建立型模式演化。當設計者在設計標準之間進行權衡的時候，瞭解多個建立型模式可以給設計者更多的選擇餘地。

2. 抽象原廠模式（Abstract Factory）

提供一個建立一系列或者相關依賴對象的介面，而無需指定它們具體的類。

3. 建造者模式（Builder）

將一個複雜物件的構建與它的表示分離，使得同樣的構建過程可以建立不同的表示。
內聚性與耦合性 內聚性描述的是一個常式內部組成部分之間相互聯絡的緊密程度。而耦合性描述的是一個常式與其他常式之間聯絡的緊密程度。軟體開發的目標應該是建立這樣的常式：內部完整，也就是高內聚，而與其他常式之間的聯絡則是小巧、直接、可見、靈活的，這樣就是松耦合。
將一個複雜物件的構建與它的表示分離，這就可以很容易地改變一個產品的內部表示，並且使得構造代碼和表示代碼分開。這樣對於客戶來說，它無需關心產品的建立過程，而只要告訴我需要什麼，我就能用同樣的構建過程建立不同的產品給客戶。

4. 原型模式（Prototype）

用原型的執行個體制定建立對象的種類，並且通過拷貝這些原型建立新的對象。
建立相依數目的原型並複製它們通常比每次用合適的狀態手工執行個體化該類更方便一些。

5. 單例模式（Singleton）

保證一個類僅有一個執行個體，並提供一個訪問它的全域訪問點。
對一些類來說，一個執行個體是很重要的。一個全域變數可以使得一個對象被訪問，但它不能防止客戶執行個體化多個對象。單例的優勢就是讓類自身負責儲存它的唯一執行個體。這個類可以保證沒有其他執行個體可以被建立，並且單例還提供了一個訪問該執行個體的方法。這樣就使得對唯一的執行個體可以嚴格地控制客戶怎樣以及何時訪問它。