設計模式概述

第一章：簡單工廠模式

1.物件導向的好處

通過封裝、繼承、多型把程式的耦合度降低。

用設計模式使得程式更加的靈活，容易修改，並且易於復用。

簡單工廠模式：到底要例項化誰，將來會不會增加例項化的物件，比如增加開根運算，這是很容易變化的地方，應該考慮用乙個單獨的類來做這個創造例項的過程，這就是工廠。

類圖：類圖分三層，第一層顯示類的名稱，如果是抽象類，則就用斜體顯示。第二層是類的特性，通常就是欄位和屬性。第三層是類的操作，通常是方法或行為。

程式設計是一門技術，更是一門藝術。

第二章：商場**—策略模式

商場收銀軟體

情況一：打折怎麼辦。

物件導向的程式設計，並不是類越多越好，類的劃分是為了封裝，但分類的基礎是抽象，具有相同屬性和功能的物件的抽象集合才是類。

策略模式（strategy）：它定義了演算法家族，分別封裝起來，讓他們之間可以互相替換，此模式讓演算法的變化，不會影響到使用演算法的客戶。

第三章：單一職責原則

就乙個類而言，應該僅有乙個引起它變化的原因。

如果乙個類承擔的職責過多，就等於把這些職責耦合在一起，乙個職責的變化可能會削弱或者抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當變化發生時，設計會遭受到意想不到的破壞[asd]。事實上，你完全可以找出哪些是介面，哪些是遊戲邏輯，然後進行分離。

軟體設計真正要做的許多內容，就是發現職責並把那些職責相互分離。

要去判斷是否應該分離出類來，也不難，那就是如果你能夠想到多餘乙個的動機去改變乙個類，那麼這個類就具有多於乙個的職責，就應該考慮類的職責分離。

第四章：開放封閉原則：

是說軟體實體（類、模組、函式等等）應該可以擴充套件，但是不可修改[asd]

對於擴充套件是開放的，對於更改是封閉的。

無論模組是對麼的『封閉』，都會存在一些無法對之封閉的變化。既然不可能完全封閉，設計人員必須對於他設計的模組應該對那種變化封閉做出選擇，他必須先猜測出最有可能的變化種類，然後構造抽象來隔離那些變化。

發生小變化時，就及早去想辦法應對發生更大變化的可能。也就是說，等到變化發生時立即採取行動。

在我們最初編寫**時，假設變化不會發生。檔變化發生時，我們就建立抽象來隔離以後發生的同類變化。

我們希望的是在開發工作展開不僅就知道可能發生的變化。查明可能發生的變化所等待的時間越長，要建立正確的抽象就越困難。

開放-封閉原則是物件導向設計的核心所在。遵循這個原則可以**物件導向技術所聲稱的巨大好處，也就是可維護、可擴充套件、可復用、靈活性好。開發人員應該僅對程式中呈現頻率變化的那些做出抽象，然而，對於應用程式中的每個部分都可以地進行抽象同樣不是乙個好主意。拒絕不成熟的抽象和抽象本身一樣重要。

第五章，依賴倒轉原則。

抽象不應該依賴於細節，細節應該依賴於抽象（針對介面程式設計，不是對實現程式設計）

a：高層模組不應依賴低層模組。兩個都應該依賴抽象。

b：抽象不應依賴於細節。細節應該依賴於抽象。[asd]

黎克特制轉換原則：

子型別必須能夠替換掉他們的父型別。

乙個軟體實體如果使用的是乙個父類的話，那麼一定適用於其子類，而且它察覺不出父類物件和子類物件的區別。也就是說，在軟體裡面，把父類都替換成它的子類，程式的行為沒有變化。

只有當子類可以替換掉父類，軟體單位的功能不受到影響時，父類才能真正被復用，而子類也能夠在父類的基礎上增加新的行為。

正是由於子型別的可替換性才使得父類型別的模組在無需修改的情況下就可以擴充套件。

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

設計模式 概述