一、設計模式：
設計模式是一套被反覆使用、多數人知曉的、經過分類編目的、代碼設計經驗的總結。使用設計模式是爲了可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性。 毫無疑問，設計模式於己於他人於系統都是多贏的；設計模式使代碼編制真正工程化；設計模式是軟件工程的基石脈絡，如同大廈的結構一樣。
二、設計原則：
爲什麼要提倡“Design Pattern呢？根本原因是爲了代碼複用，增加可維護性。那麼怎麼才能實現代碼複用呢？面向對象有六大原則：單一職責原則 （Single Responsiblity Principle SRP）開閉原則（Open Closed
Principle，OCP）、里氏代換原則（Liskov Substitution Principle，LSP）、依賴倒轉原則（Dependency
Inversion Principle，DIP）、接口隔離原則（Interface Segregation Principle，ISP）、合成/聚合複用原則（Composite/Aggregate Reuse Principle，CARP）、最小知識原則（Principle
of Least Knowledge，PLK，也叫迪米特法則）。開閉原則具有理想主義的色彩，它是面向對象設計的終極目標。其他幾條，則可以看做是開閉原則的實現方法。
設計模式就是實現了這些原則，從而達到了代碼複用、增加可維護性的目的。
SRP：單一職責原則即不要存在多於一個導致類變更的原因。通俗的說，即一個類只負責一項職責。
遵循單一職責原的優點有：
- 可以降低類的複雜度，一個類只負責一項職責，其邏輯肯定要比負責多項職責簡單的多；
- 提高類的可讀性，提高系統的可維護性；
- 變更引起的風險降低，變更是必然的，如果單一職責原則遵守的好，當修改一個功能時，可以顯著降低對其他功能的影響。
OPC：應對擴展開放，對於修改關閉，即應該儘量在不修改原來代碼情況下進行擴展。例如”抽象工廠模式“。
LSP：里氏替換原則通俗的來講就是：子類可以擴展父類的功能，但不能改變父類原有的功能（例如子類的引用指向父類的對象）。它包含以下4層含義：
- 子類可以實現父類的抽象方法，但不能覆蓋父類的非抽象方法。
- 子類中可以增加自己特有的方法。
- 當子類的方法重載父類的方法時，方法的前置條件（即方法的形參）要比父類方法的輸入參數更寬鬆。
- 當子類的方法實現父類的抽象方法時，方法的後置條件（即方法的返回值）要比父類更嚴格。
DIP：依賴倒置原則基於這樣一個事實：相對於細節的多變性，抽象的東西要穩定的多。以抽象爲基礎搭建起來的架構比以細節爲基礎搭建起來的架構要穩定的多。在Java中，抽象指的是接口或者抽象類，細節就是具體的實現類，使用接口或者抽象類的目的是制定好規範和契約，而不去涉及任何具體的操作，把展現細節的任務交給他們的實現類去完成。(mother
tell stories/paper...)
依賴倒置原則的核心思想是面向接口編程,
ISP：接口隔離原則是客戶端不應該依賴它不需要的接口；一個類對另一個類的依賴應該建立在最小的接口上。當一個接口會被多個類實現時，該接口中定義的方法必須是所有實現類都需用到的意義的方法，一旦有有個別實現類不需要實現某個別的方法時，需將本接口拆分爲更小更獨立的接口。
採用接口隔離原則對接口進行約束時，要注意以下幾點：
- 接口儘量小，但是要有限度。對接口進行細化可以提高程序設計靈活性是不掙的事實，但是如果過小，則會造成接口數量過多，使設計複雜化。所以一定要適度。
- 爲依賴接口的類定製服務，只暴露給調用的類它需要的方法，它不需要的方法則隱藏起來。只有專注地爲一個模塊提供定製服務，才能建立最小的依賴關係。
- 提高內聚，減少對外交互。使接口用最少的方法去完成最多的事情。
carp：
PLK：最小隻是原則（迪米特法則）：一個對象應該對其他對象保持最少的瞭解
迪米特法則的初衷是降低類之間的耦合，由於每個類都減少了不必要的依賴，因此的確可以降低耦合關係。但是凡事都有度，雖然可以避免與非直接的類通信，但是要通信，必然會通過一個“中介”來發生聯繫，例如本例中，總公司就是通過分公司這個“中介”來與分公司的員工發生聯繫的。過分的使用迪米特原則，會產生大量這樣的中介和傳遞類，導致系統複雜度變大。所以在採用迪米特法則時要反覆權衡，既做到結構清晰，又要高內聚低耦合。
相關： http://baike.baidu.com/link?url=GwXOHQXmGYdyDNhjajXYAFPPsJ8j-gktxXALpPFi0vPZe4Kfai4VjIOug-lQd6kn7N0N
客戶端不應該依賴它不需要的接口；一個類對另一個類的依賴應該建立在最小的接口上。