簡單工廠模式
緊耦合 松耦合
簡單工廠模式
用乙個單獨的類來做創造例項的過程
物件導向程式設計，不是類越多越好，類的劃分是為了封裝，分類的基礎是抽象，具有相同屬性和功能的物件的抽象集合才是類
最大的優點在於工廠類中包含了必要的邏輯判斷，根據客戶端的選擇條件動態例項化相關的類，對於客戶端來說，去除了與具體產品的依賴
缺點：違背開發-封閉原則。優點：保持了封裝物件建立過程
uml矩形框
表示乙個類
分三層：第一層顯示類的名稱，抽象類用斜體表示；第二層類的特性：字段、屬性；第三層類的操作：方法、行為
前面的符號：+ 表示public，- 表示 privae，# 表示 protected
介面圖第一種
頂端有 <
第一行：介面名稱
第二行：介面方法
第二種棒棒糖表示法
圓圈旁為介面名字，介面方法在類中實現
繼承關係
用空心三角形+實線表示
實現介面
用空心三角形+虛線表示
關聯關係
當乙個類「知道」另乙個類時
用實線箭頭表示
聚合關係
表示乙個弱的「擁有」關係，體現的是a物件可以包含b物件，但b物件不是a物件的一部分
用空心的菱形+實線箭頭表示
合成(組合)關係
是一種強的「擁有」關係，體現了嚴格的部分和整體的關係，部分和整體的生命週期一樣
用實心的菱形+實線箭頭表示
上圖連線兩端分別有數字1和2，稱為基數，即這一端的類可以有幾個例項，無數個例項用「n」表示
關聯關係、聚合關係也有基數
依賴關係
用虛線箭頭表示
策略模式
定義定了了演算法家族，分別封裝起來，讓它們之間可以互相替換，此策略讓演算法的變化，不會影響到使用演算法的客戶
解析策略模式是一種定義一系列演算法的方法，完成的都是相同的工作，只是實現不同，可以以相同的方式呼叫所有的演算法，減少了各種演算法類與使用演算法類之間的耦合
如上圖的strategy類層次為context定義了一系列的可供重用的演算法或行為。繼承有助於析取出這些演算法中的公共功能
簡化了單元測試，因為每個演算法都有自己的類，可以通過自己的介面單獨測試
當不同的行為堆砌在乙個類中時，就很難避免使用條件語句來選擇合適的行為。將這些行為封裝在乙個個獨立的strategu類中，可以在使用這些行為的類中消除條件語句
策略模式就是用來封裝演算法的，但在實踐中，我們發現可以用它來封裝幾乎任何型別的規則，只要在分析過程中聽到需要在不同時間應用不同的業務規則，就可以考慮使用策略模式處理這種變化的可能性
在基本的策略模式中，選擇所用具體實現的職責有客戶端物件承擔，並轉給策略模式的context物件
任何需求的變更都是需要成本的
單一職責原則
就乙個類而言，應該僅有乙個引起它變化的原因
如果乙個類承擔的職責過多，就等於把這些職責耦合在一起，乙個職責的變化可能會削弱或者抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當變化發生時，設計會遭受到意想不到的破壞
軟體設計真正要做的許多內容，就是發現職責並把那些職責相互分離
如果你能夠想到多於乙個的動機去改變乙個類，那麼這個類就具有多於乙個的職責
物件導向的設計其實就是希望做到**的責任分解
開放–封閉原則
定義是說軟體實體（類、模組、函式等等）應該可以擴充套件，但是不可修改
對於擴充套件時開放的，對於更改是封閉的
怎樣的設計才能面對需求的改變卻可以保持相對穩定，從而使得系統可以在第乙個版本以後不斷推出新的版本呢？開放-封閉給我們答案
何時應對變化
無論模組是多麼的「封閉」，都會存在一些無法對之封閉的變化。既然不可能完全封閉，設計人員必須對於他設計的模組應該對哪種變化封閉做出選擇。他必須先猜測出最有可能發生變化種類，然後構造抽象來隔離那些變化
等到變化發生時立即採取行動
在我們最初編寫**時，假設變化不會發生。當變化發生時，我們就建立抽象來隔離以後發生的同類變化
面對需求，對程式的改動是通過增加新**進行的，而不是更改現有的**
我們希望的是在開發工作展開不久就知道可能發生的變化。查明可能發生的變化所等待的時間越長，要建立正確的抽象就越困難
開發-封閉原則是物件導向設計的核心所在。遵循這個原則可以帶來物件導向技術所聲稱的巨大好處，也就是可維護、可擴充套件、可復用、靈活性好。開發人員應該僅對程式中呈現出頻率變化的那些部分做出抽象，然而，對於應用程式中的每個部分都刻意地進行抽象同樣不是乙個好主意。拒絕不成熟的抽象和抽象本身一樣重要
依賴倒轉原則
定義a. 高層模組不應該依賴底層模組。兩個都應該依賴抽象。b.抽象不應該依賴細節，細節應該依賴抽象
針對介面程式設計，不要對實現程式設計
依賴倒轉其實可以說是物件導向設計的標誌，用哪種語言來編寫程式不重要，如果編寫時考慮的都是如何針對抽象程式設計而不是針對細節程式設計，即程式中所有的依賴關係都是終止與抽象類或者介面，那就是物件導向的設計，反之那就是過程化的設計了
黎克特制代換原則
子型別必須能夠替換掉它們的父型別
乙個軟體實體如果使用的是乙個父類的話，那麼一定適用於其子類，而且它察覺不出父類物件和子類物件的區別。也就是說，在軟體裡面，把父類都替換成它的子類，出現的行為沒有變化
只有當子類可以替換掉父類，軟體單位的功能不受到影響時，父類才能真正被復用，而子類也能夠在父類的基礎上增加新的行為
由於子型別的可替換性才使得使用父類型別的模組在無需修改的情況下就可以擴充套件
大話設計模式讀書筆記一
1矩形框代表乙個類。如果類是抽象的，那麼要用斜體表示。第二層是字段和屬性。第三次是類的方法和行為。對應的屬性表示為 notation meaning public private protected 乙個例子就是 如果定義乙個介面。要在名稱上面加 介面也用棒棒糖語法表示 下面將類與類之間的關係。知道...
讀書筆記 大話設計模式（一）
在uml類圖中總共有 種圖示 對於類和介面，總共有兩種，下面只有一行表示方法的介面以及下面有兩行分別顯示屬性和方法的類。2.1單一職責原則 就乙個類而言，應有且僅有乙個導致它被修改的原因。也就是說，我們在設計類時，應當盡量保證每乙個類只承擔一項工作的職責，只有當這項職責發生變化，我們才需要修改類。如...
《大話設計模式》讀書筆記一
今天開始看大話設計模式，覺得通俗易懂，作為設計模式的入門書再好不過。很慚愧現在才說設計模式入門，作為不是軟體專業出身缺入了軟體行業的門的小菜，在工作後也用到了一些設計模式，但是卻沒有系統的學習，所以在讀的過程中，經常做恍然大悟狀，哦，原來叫這個名，哦，原來是這麼個原理，不過亡羊補牢，為時未晚，決定花...