設計原則
1.單一職責原則
定義：不要存在多於一個導致類變更的原因。通俗的說，即一個類只負責一項職責。
問題由來：類T負責兩個不同的職責：職責P1，職責P2。當由於職責P1需求發生改變而需要修改類T時，有可能會導致原本運行正常的職責P2功能發生故障。
解決方案：遵循單一職責原則。分別建立兩個類T1、T2，使T1完成職責P1功能，T2完成職責P2功能。這樣，當修改類T1時，不會使職責P2發生故障風險；同理，當修改T2時，也不會使職責P1發生故障風險。
2.里氏替換原則
定義1：如果對每一個類型為 T1的對象 o1，都有類型為 T2 的對象o2，使得以 T1定義的所有程序 P 在所有的對象 o1 都代換成 o2 時，程序 P 的行為沒有發生變化，那么類型 T2 是類型 T1 的子類型。
定義2：所有引用基類的地方必須能透明地使用其子類的對象。
問題由來：有一功能P1，由類A完成。現需要將功能P1進行擴展，擴展后的功能為P，其中P由原有功能P1與新功能P2組成。新功能P由類A的子類B來完成，則子類B在完成新功能P2的同時，有可能會導致原有功能P1發生故障。
解決方案：當使用繼承時，遵循里氏替換原則。類B繼承類A時，除添加新的方法完成新增功能P2外，盡量不要重寫父類A的方法，也盡量不要重載父類A的方法
只要父類能出現的地方，其子類就應該能出現。也就是用子類替換父類后，保證程序照樣運行。
里氏替換原則通俗的來講就是：子類可以擴展父類的功能，但不能改變父類原有的功能,否則可能導致原來的功能出錯。
3.依賴倒置原則
依賴倒置原則基於這樣一個事實：相對於細節的多變性，抽象的東西要穩定的多。以抽象為基礎搭建起來的架構比以細節為基礎搭建起來的架構要穩定的多。在 java中，抽象指的是接口或者抽象類，細節就是具體的實現類，使用接口或者抽象類的目的是制定好規范和契約，而不去涉及任何具體的操作，把展現細節的任 務交給他們的實現類去完成。
依賴倒置原則的核心思想是面向接口編程
4.接口隔離原則
定義：客戶端不應該依賴它不需要的接口；一個類對另一個類的依賴應該建立在最小的接口上。
問題由來：類A通過接口I依賴類B，類C通過接口I依賴類D，如果接口I對於類A和類B來說不是最小接口，則類B和類D必須去實現他們不需要的方法。
解決方案：將臃腫的接口I拆分為獨立的幾個接口，類A和類C分別與他們需要的接口建立依賴關系。也就是采用接口隔離原則
接口細化，也就是接口中的方法要盡量少。
5.迪米特法則
定義：一個對象應該對其他對象保持最少的了解。
問題由來：類與類之間的關系越密切，耦合度越大，當一個類發生改變時，對另一個類的影響也越大。
解決方案：盡量降低類與類之間的耦合。
也稱為最少知識原則，其定義為：一個對象應當對其他對象有最少的了解。也就是一個類中不要有過多的其他類。
6.開閉原則
定義：一個軟件實體如類、模塊和函數應該對擴展開放，對修改關閉。
問題由來：在軟件的生命周期內，因為變化、升級和維護等原因需要對軟件原有代碼進行修改時，可能會給舊代碼中引入錯誤，也可能會使我們不得不對整個功能進行重構，並且需要原有代碼經過重新測試。
解決方案：當軟件需要變化時，盡量通過擴展軟件實體的行為來實現變化，而不是通過修改已有的代碼來實現變化。
一個軟件實體（如類，模塊，和函數）應該對擴展開放，對修改關閉。
設計模式
一、創建型模式
1. 抽象工廠(abstract factory)
2. 生成器(builder)
3. 工廠方法(factory method)
4. 原型(prototype)
5. 單件(singleton)
二、結構型模式
1. 適配器(adapter)
2. 橋接(bridge)
3. 組成(composite)
4. 裝飾(decorator)
5. 外觀(facade)
6. 享元(flyweight)
7. 代理(proxy)
三、行為模式
1. 職責鏈(chain of responsibility)
2. 命令(command)
3. 解釋器(interpreter)
4. 迭代器(iterator)
5. 中介者(mediator)
6. 備忘錄(memento)
7. 觀察者(observer)
8. 狀態(state)
9. 策略(strategy)
10. 模版方法(template method)
11. 訪問者(visitor)