1.類圖 + (public ),- (private),# (protected)
2. 繼承關係： 空心三角形+直線表示
實現接口： 空心三角形+虛線表示
關聯關係： 實線箭頭表示
聚合關係： 空心棱形+實線箭頭表示
組合關係： 實心棱形+實線箭頭表示
依賴關係： 虛心箭頭表示
一.簡單工廠類
二.策略模式
三.開放-封閉原則
四.依賴倒轉原則
高層模塊不應依賴於低層模塊，兩個都應該依賴抽象；
抽象不應該依賴於細節，細節應該依賴於抽象；
歸根結底是要面向接口編程，不要對實現編程；
五.里氏代換原則
一個軟件實體如果使用的是一個父類的話，那麼一定適用於其子類，而且它覺察不出父類對象和子類對象的區別。（子類型必須能夠替換掉他們的父類型）；
六.裝飾模式
裝飾模式總結：
爲已有功能動態添加更多功能的一種方式，當系統需要新功能的時候，是向舊的類中添加新的代碼，這些新加的代碼通常裝飾了原有類的核心職責或主要行爲。
但這種問題做法在於它們在主類中新的字段，新的方法，新的邏輯，從而增加了主類的複雜度，而這些新加入的東西僅僅是爲了實現一些只有在特定情況下才會執行的特殊行爲的需要，而裝飾模式卻提供了一種比較好的解決方案，它把每個要裝飾的功能放在單獨的類中，並讓這個類包裝它所要裝飾的對象，因此當需要執行特殊行爲時，客戶代碼就可以在運行時，根據需要，有選擇地，按順序的使用裝飾功能包裝對象了。
裝飾模式優點：把類中的裝飾功能從類中移除，這樣可以簡化原有的類，有效的把類核心職責和裝飾功能分離，而且可以去掉相關類中重複的裝飾邏輯；
七 代理模式
代理模式（Proxy)，爲其他對象提供一種代理以控制對這個對象的訪問。
代理模式應用場合：
a.遠程代理，也就是爲一個對象在不同的地址空間提供局部代表，這樣可以隱藏一個對象存在於不同地址空間的事實。
b.虛擬代理，也就是根據需要創建開銷很大的對象，通過它來存放實例化需要很長時間的真實對象。
c.安全代理，用來控制真實對象訪問時的權限。
d.智能引用，是指當調用真實的對象時，代理處理另外的一些事。
八.工廠方法模式
工廠方法模式實現時，客戶端需要決定實現實例化哪一個工廠來實現運算類，選擇判斷的問題還是存在的，也就是說工廠方法把簡單工廠內部邏輯判斷轉移到了客戶端代碼來執行，你想要加功能，本來是該工廠類的，而現在修改客戶端
九.原型模式（Prototype）
原型模式：實際上從一個對象再創建另外一個可定製的對象，而且不需要知道任何創建的細節。
十.模板方法模式。
模板方法模式：定義一個操作中的算法的骨架，而將一些步驟延遲到子類中，模板方法使得子類可以不改變一個算法的結構即可重新定義該算法的某些特定步驟。
模板方法模式是通過把不變的行爲搬移到超類，去除子類中的重複代碼來體現它的優勢，模板方法模式提供了一個很好的代碼複用平臺。
十一.迪米特法則（LoD)也叫最少知識原則；
如果兩個類不必彼此直接通信，那麼這兩個類就不應當發生直接的相互作用，如果一個類需要調用另一個類的某一個方法的話，可以通過第三者轉發這個調用。
強調類之間的低耦合，類之間的耦合越弱，越有利於複用，一個處在弱耦合的類被修改，不會對有關係的類產生波及。
十二.外觀模式（facade)
外觀模式適用範圍：軟件設計之初，將不同的層分離，層與層之間建立外觀，減少他們之間的依賴，對於遺留系統（難於維護的系統），可以考慮爲新系統開發一個外觀類，讓新系統和facade對象交互，facade與遺留代碼交互所有複雜的工作。
十三.建造者模式（生成器模式-builder)
建造者模式：將一個複雜對象的構建和他的表現分離，使得同樣的構建過程可以創建不同的表示；
十四.觀察者模式（發佈-訂閱模式publish/subscribe）；
觀察者模式：定義了一種一對多的依賴關係，讓多個觀察者對象同時監聽某一個主題對象。這個主題對象在狀態發生變化時，會通知所有觀察者對象，使他們自動能更新自己。
將一個系統分割成一系列相互協作的類有一個很不好的副作用，那就是需要維護相關對象間的一致性，我們不希望爲了維護一致性而使個個類緊密耦合，這樣會
給 維護，拓展和重用都帶來不便。
適用場合： 當一個對象的改變，需要同時改變其他對象，而且它不知道具體有多少對象有待改變時應該考慮用觀察者模式。觀察者模式所做的工作就是解耦，讓耦合的雙
方 都依賴於抽象，而不依賴於具體，從而使得各自的變化，都不影響到另一邊的變化。
十五.抽象工廠
抽象工廠模式（Abstract Factory) : 提供一個創建一系列相關或相互依賴對象的接口，而無需指定它們具體的類。
優點：便於交換產品系統，由於具體工廠類在一個應用中只需要在初始化的時候出現一次，這就使得改變一個應用的具體工廠變得非常容易，它只
需 要改變具體工廠 即可使用不同的產品配置。它讓具體的創建實例過程與客戶端分離，客戶端通過它們的抽象接口操縱實例，產品的具體類
名也被具體工廠的實現分離，不會出現在客戶代碼中。
缺點：增加功能時，修改代碼太大。
十六.狀態模式
狀態模式（State）, 當一個對象的內在狀態改變時允許改變其行爲，這個對象看起來像是改變了其類。狀態模式主要解決的是當控制一個
對象狀態轉換的條件表達式過於複雜 時的情況。把狀態的判斷邏輯轉移到表示不同狀態的一系列類當中，可以把複雜的判斷邏輯簡化。
狀態模式優點：將與特定狀態相關的行爲局部化，並且將不同狀態的行爲分割開來。消除龐大的條件分支語句。
狀態模式使用場合：當一個對象的行爲取決於它的狀態，並且在它必須在運行時刻根據狀態改變其行爲時，就可以考慮使用狀態模式了。
十七.適配器模式
適配器模式（Adapter) : 將一個類的接口轉換成客戶希望的另外一個接口。Adapter模式使得原本由於接口不兼容而不能一起工作的那些類
可以一起工作。在軟件開發中系統的數據和行爲都正確，但接口不符時，我們應該考慮使用適配器，目的是使控制，
範圍之外的一個原有對象與某個接口匹配，適配器模式適用於希望複用一些現存的類，但是接口又與複用環境要求不一致的情況。
十八.備忘錄模式
備忘錄模式使用場合：功能比較複雜的系統，但需要維護或記錄屬性歷史的類，或者需要保存屬性只是衆多屬性中的一小部分。如果某個系統使用命令模式，需要實現命令的撤銷功能，，那麼命令模式可以用備忘錄模式來存儲可撤銷的操作的狀態。使用備忘錄可以把複雜的對象內部信息，對其他對象屏蔽起來。
十九.組合模式
組合模式:
需求中是體現部分和整體層次的結構時，以及你希望用戶可以忽略組合對象與單個對象的不同，統一地使用組合結構中的所有對象時，就應該考慮用組合模式了。
組合模式讓客戶可以一致的使用組合結構和單個對象。
二十.迭代器模式
迭代器模式（Iterator)： 提供一種方法順序訪問一個聚合對象中各個元素，而又不暴露該對象的內部表示。
迭代器模式適用場合：當你需要訪問一個聚集對象，而不管這些對象是什麼，都需要遍歷的時候，就應該考慮使用迭代器模式。
爲遍歷不同的聚集結構提供如開始，下一個，是否結束，當前哪一些等統一地接口。
二十一.單例模式
單例模式（Singleton）：僅保證一個類產生一個實例，並提供一個訪問它的全局訪問點。
(餓漢式單例）
public class Singleton{
private static Singleton instance = new Singleton();
private Singleton (){
};
public static Singleton getInstance(){
return instance ;
}
}
（飽汗式單例）
public class Singleton{
private static Singleton instance ;
private Singleton(){};
public static Singleton getInstance (){
if (null==instance){
instance = new Singleton()；
}
return instance;
}
}
比較理想方式：
public class Singleton{
private static Singleton instance ==null;
private Singleton (){
};
public static syschornized Singleton getInstance(){
if(null==instance ){
instance = new Singleton();
}
return instance;
}
}
}
最爲理想方式：
public class Singleton {
private static class Singletonholder{
public static Singleton instance = new Singleton ();
}
public Singleton getInstance (){
return Singletonholder.instance;
}
}
二十二.橋接模式
合成/聚合複用原則：儘量使用合成/聚合，儘量不要使用類繼承。
合成/聚合的好處：優先使用對象的合成/聚合將有助於你保持每個類被封裝，並被集中在單個任務上，這樣類和類繼承層次會保持規模較小，並且不太可能增長爲不可控制的龐然大物。
橋接模式（Bridge）：將抽象部分與他的實現部分分離，使它們都可以獨立的變化。
通俗理解：實現系統可能有多個角度分類，每一個分類都有可能變化，那麼就把這種多角度分離出來讓它們獨立變化，減少它們之間的耦合。
二十三.命令模式
命令模式優點：
第一，它能較容易地設計一個命令隊列；
第二，在需要的情況下，可以比較容易地將命令記入日誌；
第三，允許接收請求的一方決定是否要否決請求；
第四，可以容易地實現對請求的撤銷和重做；
第五，由於加進新的工具命令類，不影響其他的類，因此增加新的具體命令類很容易。，命令模式把請求一個操作的對象與指導怎麼執行一個操作的對象分割開。
二十四.職責鏈模式.
職責鏈模式（Chain of Responsibility): 使多個對象都有機會處理請求，從而避免請求的發送者和接收者之間的耦合關係。將這個對象連成
一條鏈，並沿着這條鏈傳遞該請求，直到有一個對象處理它爲止。
二十五.中介者模式
中介者模式優缺點：中介者模式很容易在系統中應用，也很容易在系統中誤用。當系統中出現了多對多交互複雜的對象羣時，不要急於使用中介者模式
而要先反思你的系統在設計上是不是合理。
優點：Mediator的出現減少了各個Colleague的耦合，使得可以獨立地改變和複用各個Colleague類和Mediator。由於把對象如何協作進行了抽象，
將中介作爲一 個 獨立的概念並將其封裝在一個對象中，這樣關注的對象就從對象各個本身的行爲轉移到了它們之間的交互上來，也就是站在
一個更宏觀的角度去看待系統。
缺點：由於ConcretMediator控制了集體化，於是就把交互複雜性變爲了中介者的複雜性，就使得中介者會變得比任何一個ConcreteColleague都複雜。
二十六.享元模式
享元模式使用場合：如果一個應用程序使用了大量的對象，而大量的這些對象造成了很大的存貯開銷時就應該考慮，還有就是對象的大多數狀態可以外部狀態，如果
刪除對象的外部狀態，那麼可以用相對較少的共享對象取代很多組對象，此時可以考慮使用享元模式。
二十七.解釋器模式。
解釋器模式（interpreter),給定一個語言，定義他的文法的一種表示，並定義一個解釋器，這個解釋器使用該表示來解釋語言中的句子。
解釋器模式需要解決的是，如果一種特定類型的問題發生的頻率足夠高，那麼可能就值得將該問題的各個實例表達爲一個簡單語言中
的句子。這樣就可以構建一個解釋器，該解釋器通過解釋這些句子來解決該問題。
解釋器模式好處： 當有一個語言需要解釋執行，並且你可將該語言中的句子表示爲一個抽象語法樹時，可使用解釋器模式。用瞭解釋器模式
這意味着可以很容易的改變和拓展文法，因爲該模式使用類來表示文法規則，你可以使用繼承來改變或拓展該文法，也比
較容易實現文法，因爲定義抽象語法樹中各個節點的類的實現大體類似，這些類都易於編寫。
解釋器不足： 解釋器模式爲文法中的每一條規則至少定義了一個類，因此包含了許多規則的文法可能難以管理和維護，建議當文法非常複雜時，使用其他技術如語法分析
程 序或者編譯器生存器來處理。
二十八.訪問者模式
訪問者模式：訪問者模式適用於數據結構相對穩定的系統，它把數據結構和作用於結構上的操作之間的耦合解脫開，使得操作集合可以相對自由的演化。
訪問者模式的目的是要把處理從數據結構分離出來。訪問者模式的優點就是增加新的操作很容易，因爲增加新的操作就意味着增加一個新的
訪問者，訪問者模式將有管的行爲集中到一個訪問者對象中。