設計模式

設計模式（Design pattern）是一套被反覆使用、多數人知曉的、通過分類編目的、代碼設計經驗的總結。使用設計模式是爲了可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性。 毫無疑問，設計模式於己於他人於系統都是多贏的；設計模式使代碼編制真正工程化；設計模式是軟件工程的基石脈絡，如同大廈的結構同樣。

設計模式分爲三種類型，共23種。

• 建立型模式：單例模式、抽象工廠模式、建造者模式、工廠模式、原型模式。
• 結構型模式：適配器模式、橋接模式、裝飾模式、組合模式、外觀模式、享元模式、代理模式。
• 行爲型模式：模版方法模式、命令模式、迭代器模式、觀察者模式、中介者模式、備忘錄模式、解釋器模式、狀態模式、策略模式、職責鏈模式、訪問者模式。

按字典序排列簡介以下。

1. Abstract Factory（抽象工廠模式）：提供一個建立一系列相關或相互依賴對象的接口，而無需指定它們具體的類。
2. Adapter（適配器模式）：將一個類的接口轉換成客戶但願的另一個接口。Adapter模式使得本來因爲接口不兼容而不能一塊兒工做的那些類能夠一塊兒工做。
3. Bridge（橋接模式）：將抽象部分與它的實現部分分離，使它們均可以獨立地變化。
4. Builder（建造者模式）：將一個複雜對象的構建與它的表示分離，使得一樣的構建過程能夠建立不一樣的表示。
5. Chain of Responsibility（職責鏈模式）：爲解除請求的發送者和接收者之間耦合，而使多個對象都有機會處理這個請求。將這些對象連成一條鏈，並沿着這條鏈傳遞該請求，直到有一個對象處理它。
6. Command（命令模式）：將一個請求封裝爲一個對象，從而使你可用不一樣的請求對客戶進行參數化；對請求排隊或記錄請求日誌，以及支持可取消的操做。
7. Composite（組合模式）：將對象組合成樹形結構以表示「部分-總體」的層次結構。它使得客戶對單個對象和複合對象的使用具備一致性。
8. Decorator（裝飾模式）：動態地給一個對象添加一些額外的職責。就擴展功能而言， 它比生成子類方式更爲靈活。
9. Facade（外觀模式）：爲子系統中的一組接口提供一個一致的界面，Facade模式定義了一個高層接口，這個接口使得這一子系統更加容易使用。
10. Factory Method（工廠模式）：定義一個用於建立對象的接口，讓子類決定將哪個類實例化。Factory Method使一個類的實例化延遲到其子類。
11. Flyweight（享元模式）：運用共享技術有效地支持大量細粒度的對象。
12. Interpreter（解析器模式）：給定一個語言, 定義它的文法的一種表示，並定義一個解釋器, 該解釋器使用該表示來解釋語言中的句子。
13. Iterator（迭代器模式）：提供一種方法順序訪問一個聚合對象中各個元素，而又不需暴露該對象的內部表示。
14. Mediator（中介模式）：用一箇中介對象來封裝一系列的對象交互。中介者使各對象不須要顯式地相互引用，從而使其耦合鬆散，並且能夠獨立地改變它們之間的交互。
15. Memento（備忘錄模式）：在不破壞封裝性的前提下，捕獲一個對象的內部狀態，並在該對象以外保存這個狀態。這樣之後就可將該對象恢復到保存的狀態。
16. Observer（觀察者模式）：定義對象間的一種一對多的依賴關係,以便當一個對象的狀態發生改變時,全部依賴於它的對象都獲得通知並自動刷新。
17. Prototype（原型模式）：用原型實例指定建立對象的種類，而且經過拷貝這個原型來建立新的對象。
18. Proxy（代理模式）：爲其餘對象提供一個代理以控制對這個對象的訪問。
19. Singleton（單例模式）：保證一個類僅有一個實例，並提供一個訪問它的全局訪問點。 單例模式是最簡單的設計模式之一，可是對於Java的開發者來講，它卻有不少缺陷。在九月的專欄中，David Geary探討了單例模式以及在面對多線程（multi-threading）、類裝載器（class loaders）和序列化（serialization）時如何處理這些缺陷。
20. State（狀態模式）：容許一個對象在其內部狀態改變時改變它的行爲。對象看起來彷佛修改了它所屬的類。
21. Strategy（策略模式）：定義一系列的算法,把它們一個個封裝起來, 而且使它們可相互替換。本模式使得算法的變化可獨立於使用它的客戶。
    Template Method（模板方法模式）：定義一個操做中的算法的骨架，而將一些步驟延遲到子類中。Template Method使得子類能夠不改變一個算法的結構便可重定義該算法的某些特定步驟。
    Visitor（訪問者模式）：表示一個做用於某對象結構中的各元素的操做。它使你能夠在不改變各元素的類的前提下定義做用於這些元素的新操做。

設計原則

一、開閉原則
此原則是由Bertrand Meyer提出的。原文是：「Software entities should be open for extension,but closed for modification」。就是說模塊應對擴展開放，而對修改關閉。模塊應儘可能在不修改原（是「原」，指原來的代碼）代碼的狀況下進行擴展。
二、里氏代換原則
里氏代換原則是由Barbara Liskov提出的。若是調用的是父類的話，那麼換成子類也徹底能夠運行。
三、依賴倒轉原則
抽象不該該依賴於細節，細節應當依賴於抽象。要針對接口編程，而不是針對實現編程。傳遞參數，或者在組合聚合關係中，儘可能引用層次高的類。主要是在構造對象時能夠動態的建立各類具體對象，固然若是一些具體類比較穩定，就沒必要在弄一個抽象類作它的父類，這樣有多此一舉的感受。
四、接口隔離原則
定製服務的例子，每個接口應該是一種角色，很少很多，不幹不應乾的事，該乾的事都要幹。
五、合成/聚合複用
合成/聚合複用原則（Composite/Aggregate Reuse Principle，CARP）常常又叫作合成複用原則。合成/聚合複用原則就是在一個新的對象裏面使用一些已有的對象，使之成爲新對象的一部分；新的對象經過向這些對象的委派達到複用已有功能的目的。它的設計原則是：要儘可能使用合成/聚合，儘可能不要使用繼承。
六、最少知識原則
也叫迪米特法則。不要和陌生人說話，即一個對象應對其餘對象有儘量少的瞭解。