1矩形框代表乙個類。如果類是抽象的，那麼要用斜體表示。第二層是字段和屬性。第三次是類的方法和行為。對應的屬性表示為
notation
meaning
+public
-private
#protected
乙個例子就是
如果定義乙個介面。要在名稱上面加<>介面也用棒棒糖語法表示
下面將類與類之間的關係。
知道另外乙個類的存在
**示例
class penguin:bird
合成是一種強的擁有關係，體現了嚴格的部分和整體之間的關係。部分和整體的生命週期是一樣的。用實心實現表示。
}依賴關係用虛線箭頭表示，也是用得到的意思
}有了基本的uml知識，我們就可以方便的交流了。
通過工廠建立類，可以對類進行集中管理。比如在編寫計算器過程中，可以建立乙個運算工廠，用運算工廠實現各種運算。可以降低檢視和操作間的耦合度
它定義了演算法家族，分別封裝起來，讓他們直接可以互相替換，這些演算法都是完成相同的工作，只是實現不同。如字型排版，是按照什麼演算法排版確實有很多種變化。此模式讓演算法的變化，不會影響到使用演算法的使用者。當然策略模式不僅可以封裝乙個演算法，只要在不同的時間實現不同的業務規則就可以考慮策略模式。策略模式可以和工廠模式聯合起來使用。
比如排版我們可以建立乙個 排版類。客戶端呼叫排版類可以這樣
new排版類(「方式一」).這樣排版類可以在建構函式中呼叫排版演算法工程類更具「方式一」這個引數返回乙個演算法類加入到排版類中。然後執行就可以。書中給了另外乙個例子
就乙個類而言，應該僅有乙個因其他變化的原因。也可以理解為乙個類只幹乙個活。也就是不要設計複雜的類。
軟體實體（類，模組，函式等等）應該可以擴充套件，但是不可修改。這個和繼承非常像
第一條高層模組不應該依賴底層模組。兩個都應該依賴抽象。這裡可以按照黎克特制代換原則理解，就是子型別必須能夠替換掉他們的父型別。乙個軟體屍體如果使用是乙個父類的話，那麼一定使用於其子類，而且察覺不出父類物件和子類物件的區別。也就是說，在軟體裡面，把父類都替換成它的子類，那麼程式的行為沒有變化。案例就是如果希望更好資料庫，那麼高層的軟體不需要做任何修改，只要替換掉資料庫驅動就好。
第二條抽象不應該依賴細節。細節應該依賴抽象。這兩條的意思說白了是面向介面程式設計，不要面向實現程式設計。正是由於可以替換掉底層的**，所以高層的**才能夠得到復用。
動態地給乙個物件新增一些額外的職責，就增加功能來說，裝飾模式比生成子類更加靈活這裡。我們可以在中實現乙個人的基本內容。或者可以建立乙個單獨的人的子類，用來實現人的基本內容。之後在每個類都要實現乙個函式名字叫裝飾，傳入引數為人。這樣每個衣服呼叫 裝飾（人）這樣就可以拿著衣服找人了，我們也可以衣服裝飾衣服（後面的衣服裡面修飾乙個人，類似於遞迴的意思）
這種方法的有點就是，我們可以隨時多種靈活的拓展人的表現行為。並在，我們去掉所有的裝飾還是本身人這個類。不用修改人這個類的**
為其他物件提供一種**以控制對這個物件的訪問**模式要和真正的類實現統一個介面。然後在**類裡面儲存乙個真實類的引用。然後呼叫真實類執行操作。。**可以隱藏一些東西。用來提高安全性。
讀書筆記 大話設計模式（一）
在uml類圖中總共有 種圖示 對於類和介面，總共有兩種，下面只有一行表示方法的介面以及下面有兩行分別顯示屬性和方法的類。2.1單一職責原則 就乙個類而言，應有且僅有乙個導致它被修改的原因。也就是說，我們在設計類時，應當盡量保證每乙個類只承擔一項工作的職責，只有當這項職責發生變化，我們才需要修改類。如...
《大話設計模式》讀書筆記一
今天開始看大話設計模式，覺得通俗易懂，作為設計模式的入門書再好不過。很慚愧現在才說設計模式入門，作為不是軟體專業出身缺入了軟體行業的門的小菜，在工作後也用到了一些設計模式，但是卻沒有系統的學習，所以在讀的過程中，經常做恍然大悟狀，哦，原來叫這個名，哦，原來是這麼個原理，不過亡羊補牢，為時未晚，決定花...
讀書筆記 大話設計模式
大話設計模式 的確寫的很不錯。把晦澀解懂的設計模式，講的通俗易懂。邊讀邊用evernote做筆記，把印象深刻的整理了一下。先補習一下uml的圖示法 繼承，介面，組合，依賴，關聯 策略模式 strategy 定義一系列演算法，所有演算法完成的都是相同的工作，只是實現不同。減少演算法與使用類之間的藕合。...