設計模式（Design Patterns）
1. 設計模式定義
設計模式（Design Patterns) 是一套被反覆使用、多數人知曉的、經過分類編目的、代碼設計經驗的總結。使用設計模式是爲了可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性。 毫無疑問，設計模式於己於他人於系統都是多贏的，設計模式使代碼編制真正工程化，設計模式是軟件工程的基石，如同大廈的一塊塊磚石一樣。項目中合理的運用設計模式可以完美的解決很多問題，每種模式在現在中都有相應的原理來與之對應，每一個模式描述了一個在我們周圍不斷重複發生的問題，以及該問題的核心解決方案，這也是它能被廣泛應用的原因。
2. 設計模式分類
廣泛的認知中，面向對象的設計模式總共分爲23種，其中又可歸納爲3個大類型：創建型模式（5種）、結構型模式（7種）、行爲型模式（11種）。
2.1. 創建型模式
創建型模式共5種，分別是工廠方法模式、抽象工廠模式、單例模式、建造者模式以及原型模式。
2.2. 結構型模式
結構型模式共7種，分別是適配器模式、裝飾器模式、代理模式、外觀模式、橋接模式、組合模式以及享元模式。
2.3. 行爲型模式
行爲型模式共11種，分別是策略模式、模板方法模式、觀察者模式、迭代子模式、責任鏈模式、命令模式、備忘錄模式、狀態模式、訪問者模式、中介者模式、解釋器模式。
3. 設計模式六大原則
3.1. 開放閉合原則（Open-Closed Principle，OCP）
軟件實體應該是可擴展，而不可修改的。開放封閉原則主要體現在兩個方面：對擴展開放，意味着有新的需求或變化時，可以對現有代碼進行擴展，以適應新的情況；對修改封閉，意味着類一旦設計完成，就可以獨立完成其工作，而不要對類進行任何修改。
3.2. 接口隔離原則（Interface Segregation Principle，ISP）
一個類對另外一個類的依賴性應當是建立在最小的接口上的。不要強迫客戶使用它們不用的方法，如果強迫用戶使用它們不使用的方法，那麼這些客戶就會面臨由於這些不使用的方法的改變所帶來的改變。
3.3. 單一職責原則（Simple Responsibility Principle，SRP）
一個類，只有一個引起它變化的原因。也就是說，它只有單一的職責，避免一個類承擔的職責過多，否則就等同於把這些職責耦合在一起了，這會導致脆弱的設計，當一個職責發生變化時，可能會影響其它的職責。其核心就是解耦和增強內聚性。
3.4. 最少知識原則 （Least Knowledge Principle，LKP）
也稱迪米特法則，一個軟件實體應當儘可能少的與其他實體發生相互作用。每一個軟件單位對其他的單位都只有最少的知識，而且侷限於那些與本單位密切相關的軟件單位。
3.5. 里氏替換原則(Liskov Substitution Principle，LSP)
子類可以擴展父類的功能，但不能改變父類原有的功能。具體體現爲：
1）子類可以實現父類的抽象方法，但不能覆蓋父類的非抽象方法。
2）子類中可以增加自己特有的方法。
3）當子類的方法重載父類的方法時，方法的前置條件（即方法的形參）要比父類方法的輸入參數更寬鬆。
4）當子類的方法實現父類的抽象方法時，方法的後置條件（即方法的返回值）要比父類更嚴格。
3.6. 依賴倒置原則（Dependence Inversion Principle，DIP）
高層模塊不應該依賴低層模塊，二者都應該依賴其抽象；抽象不應該依賴細節；細節應該依賴抽象。