設計模式入門--自己的理解

1.重載
方法名一樣，參數不一樣。比如不同的構造方法
2.封裝
對象，其實就是一個類，把它自己的成員和方法在自己的類裏面實現，自己搞自己的，不依賴別人，同時提供對外的接口
3.繼承
子類繼承父類，如果一些類有很多共同的代碼，可以抽象出來搞一個父類，然後子類來繼承，一個類只能繼承一個父類。
4.多態
父類的一個方法爲虛方法，內部沒有具體實現，子類繼承過來後，自己去實現，也就是說，方法名一樣，但是不同的子類做的事情是不一樣的。
5.重構
簡單的說就是代碼太亂，或者重複的太多，使之結構化，或者把相同的放到父類中去。
6.抽象類
其實也是多態，抽象方法沒有方法體，就是說沒有{}。子類繼承過來後自己去實現，現在搞多態，就是將父類搞成抽象類。
7.接口
聲明接口和聲明抽象類完全一樣，但不許提供接口中任何成員的執行方法。一個類可以實現多個接口。
8.集合與泛型
List Set Map 就是集合。在new的時候，比如List s =new List()，那麼這個指定類型的聲明就是泛型。
9.簡單工廠模式
我們需要實例化很多的類，那麼我們就搞一個類來專門實例化，這就是工廠，即搞一個類來專門批量的做同一個事情。不符合開放-封閉原則，因爲每次擴展都要更改工廠類。
10.策略模式
封裝算法，一個抽象的算法基類，具體策略繼承它，自己實現自己的行爲，還有一個專門實例化的類，參數就是具體的策略類。
11.單一職責
一個類而言，應該僅有一個引起它變化的原因。在類中，發現職責，並將其分離，一個類，不需要有太多的功能。
12.開放–封閉
軟件實體（類，函數，模塊）對擴展是開放的，對更改是封閉的。面對需求的改變可以使軟件保持相對穩定，就是說不影響原來的。在開發下一個版本的時候，上一個版本用戶要正常使用。
13.依賴倒轉
高層模塊不應該依賴低層模塊，兩個都應該依賴抽象。抽象不應該依賴細節，細節應該依賴抽象。針對接口編程，不要對實現編程。所有的依賴都終止於抽象或者接口，這就是面向對象。在編程的時候，行爲分離，多搞些抽象和接口用來繼承。這樣的話，易擴展，易維護，還靈活。
14.裝飾模式
把類中的裝飾功能給搬移出去，動態的增加新的功能。把每個要裝飾的功能放在單獨的類中，並讓這個類包裝它所要裝飾的對象。
15.代理模式
爲其他對象提供一種代理，以控制對這個對象的訪問。一個裏面有另外一個的實例，可以調用另外一個的方法。
16.工廠方法模式
定義一個用於創建對象的接口，讓子類決定實例化哪一個類。工廠方法讓一個類的實例化延遲到子類。
17.原型模式
用原型實例指定創建對象的種類，並且通過拷貝這些原型創建新的對象。從一個對象再創建另外一個可定製的對象，而且不需要知道任何創建的細節。簡單的說就是我new了一個對象，但是我現在需要很多這個對象，那就令新的對象=之前的創建的對象就行了，相當於是複製。淺拷貝：被複制的對象所有的變量都和原來的對象相同的值。深拷貝：把引用對象的變量指向複製過的新對象，而不是原有的被引用的對象。
18.模板方法模式
把不變的行爲搬移到超類中去，去除子類中的重複代碼來體現它的優勢。定義一個操作中的算法的骨架，而將一些步驟延遲到子類中。使得子類可以不改變一個算法的結構即可重新定義該算法的某些特定步驟。提供一個很好的代碼複用平臺。
19.迪米特法則
讓兩個類之間儘量耦合弱，這樣利於複用，一個類被修改了，不會對有關係的類造成波及。如果需要調用另一個類的方法的話，可以通過第三者轉發這個調用。
20.外觀模式
爲子系統中的一組接口提供一個一致的界面，此模式定義了一個高層接口，這個接口使得這一子系統更加容易使用。層與層分離，減少依賴。修改子系統不影響用戶，因爲外觀沒變，外觀就是一個接口，連接子系統與客戶的橋樑。
21.建造者模式
將一個複雜對象的構建與它的表示分離，使得同樣的構建過程可以創建不同的表示。用戶只需要制定建造的類型，不需要知道細節。跟編程很類似，很多類或者方法都是封裝好的，我們只需要自己調用就行了，至於內部細節代碼我們是不知道的。是在創建複製對象的算法應該獨立於該對象的組成部分以及它們的裝配方式時適用的模式。
22.觀察者模式
一對多的依賴關係，多個觀察者對象同時監聽某一個被觀察者對象，被觀察者發生變化時，會通知所有的觀察者對象，使它們可以自動更新自己。其實就是解除耦合，其實也滿足了依賴倒轉，雙方都依賴抽象，不依賴具體。Observer對象是觀察者，Observable對象是被觀察者。（1）創建被觀察者類，它繼承自java.util.Observable類。（2）創建觀察者類，它實現java.util.Observer接口。（3）被觀察者類。addObserver（）把觀察者對象添加到觀察者對象列表中，當被觀察事件發生時，setChange():用來設置一個內部標誌位註明數據發生了變化。notifyObservers()：調用觀察者對象列表中所有的Observer的updata()方法，通知它們數據發生了變化。只有在setChange()被調用後，notifyObservers()纔會去調用updata()。（4）觀察者類，實現void update(Observable o,Object arg)
23.抽象工廠模式
提供一個創建一系列相關或相互依賴對象的接口，而無需指定它們具體的類。
24.狀態模式
當一個對象的內在狀態改變時允許改變其行爲，這個對象看起來像是改變了其類。當控制一個對象狀態轉換的條件表達式過於複雜時的情況。把狀態的判斷邏輯轉移到表示不同狀態的一系列類當中，可以把複雜的判斷邏輯簡化。
25.適配器模式
將一個類的接口轉換成用戶希望的另外一個接口。使得原本由於接口不兼容而不能一起工作那些類可以一起工作。想使用一個已經存在的類，但如果他的接口，就是方法和你的要求不一樣的時候，就可以考慮使用適配器模式。兩個類所做的事情相同或者相似，但是具有不同的接口要使用它。
26.備忘錄模式
在不破壞封裝性的前提下，捕獲一個對象的內部狀態，並在該對象之外保存這個狀態。這樣以後就可將該對象恢復到原先保持的狀態。比較適用於功能比較複雜的，但是需要維護或者記錄屬性歷史的類，或者需要保存的屬性只是衆多屬性中的一小部分時，可以根據保存的信息還原到前一狀態。
27.組合模式
將對象組合成樹形結構以表示‘部分-整體’的層次結構。組合模式使得用戶對單個對象和組合對象的使用具有一致性。當你發現需求是體現部分與整體層次結構時，以及希望用戶可忽略組合對象與單個對象的不同，統一的使用組合結構中的所有對象時，就應該考慮用組合模式了。
28.迭代器模式
提供一種方法順序訪問一個聚合對象中各個元素，而又不暴露該對象的內部表示。當你對聚集有多種方式遍歷時，可以考慮用迭代器模式。迭代器模式就是分離了集合對象的遍歷行爲，抽象出一個迭代器來負責，這樣既可以做到不暴露集合的內部結構，又可以讓外部代碼透明的訪問集合內部的數據。
29.單例模式
保證一個類僅有一個實例，並提供一個訪問它的全局訪問點。因爲實例化是需要佔用內存空間的，這樣的單例模式使得代碼清晰，內存佔用少。
30.橋接模式
將抽象部分與它的實現部分分離，使它們都可以獨立的變化。比如我現在要畫畫，如果用蠟筆，我需要12種不同的顏色以及大中小號，於是我需要36只蠟筆，那麼我就要創建36個類，如果我使用的是毛筆，我需要大中小號3只毛筆，再配上12種顏料，我只需要創建3+12=15個類。
31.命令模式
將一個請求封裝爲一個對象，從而使你可用不同的請求對客戶進行參數化，對請求排隊或記錄請求日誌，以及支持可撤銷的操作。把請求一個操作的對象與知道怎麼執行一個操作的對象分割開。
32.職責鏈模式
使多個對象都有機會處理請求，從而避免請求的發送者和接收者之間的耦合關係。將這個對象連成一條鏈，並沿着這條鏈傳遞請求，直到有一個對象處理它爲止。
33.中介者模式
用一箇中介對象來封裝一系列的對象交互。中介者使對象不需要顯示地相互引用，從而使其耦合鬆散，從而可以獨立地改變它們之間的交互。
34.享元模式
運用共享技術有效的支持大量細粒度的對象。
35.解釋器模式
給定一個語言，定義它的文法的一種表示，並定義一個解釋器，這個解釋器使用該表示來解釋語言中的句子。如果一種特定的發生的頻率足夠高，那麼可能就值得將該問題的各個實例表述爲一個簡單語言中的句子。這樣就可以構建一個解釋器，該解釋器通過解釋這些句子來解決該問題。
36.訪問者模式
表示一個作用於某對象結構中的各元素的操作。它使你可以在不改變各元素的類的前提下定義作用於這些元素的新操作。目的是要把處理從數據結構分離出來。有比較穩定的數據結構，又有易於變化的算法的話，使用訪問者模式就是比較合適的，因爲訪問者模式使得算法操作的增加變得容易。