在軟件開發中，前人總結了六大設計原則如下：
- Single Responsibility Principle：不能有多個導致類變更的原因。一個類中應該是一組相關性很高的函數、數據的封裝。一個類只負責一個職責。這個原則不僅僅適用於類，對於接口和方法也適用，而且接口和方法的單一職責更容易實現。實際開發中，這是一個備受爭議卻又及其重要的原則。——單一職責原則
- Liskov Substitution Principle：就是隻要父類出現的地方子類就可以出現，且替換成子類也不會出現任何錯誤或者異常；但是反過來，有子類出現的地方，父類不一定可以適用。也就是說，子類可以擴展父類的功能，但不能改變父類原有的功能。①子類可以實現父類的抽象方法，但不能覆蓋父類的非抽象方法。②子類可以有自己的個性，所以子類出現的地方父類就不一定適用。③實現父類的方法時，形參的類型可以被放大。④實現父類的方法時，返回值的類型可以縮小。通過里氏替換來達到對擴展開放，對修改關閉的效果。——里氏替換原則
- Dependence Inversion Principle：面向接口/抽象編程。①模塊間的依賴關係通過接口和抽象類產生，實體類之間不直接發生依賴關係。②接口和抽象類不依賴於實現類。③實現類依賴接口或者抽象類。模塊間的依賴通過抽象發生，實現類之間不發生直接的依賴關係，其依賴關係是通過接口或抽象類產生的。——依賴倒置原則
- Interface Segregation Principle：客戶端不應該依賴它不需要的接口。接口/抽象中的方法儘量少。單一職責原則是按照職責（業務邏輯）進行劃分接口的，而接口隔離原則則是按照實現類對方法的使用來劃分的。可以說，接口隔離原則更細一些。①接口儘量小。根據具體業務把一個接口按照接口隔離原則細化成更多的接口。但是在此基礎之上必須不能違背單一職責原則。②接口要高內聚。就是說，在接口內部實現的方法，不管怎麼改，都不會影響到接口外的其他接口或是實現類，只能影響它自己。③定製服務。定製服務就是單獨爲一個個體提供服務，即只提供訪問者需要的方法。④接口設計是有限度的。接口設計越小越好，但是結構同時會變得複雜，維護也變得難了。因此就要把握住這個度。——接口隔離原則
- Law of Demeter：也叫最少知道原則。一個對象應該對其他對象有最少的瞭解。低耦合、高內聚。——迪米特法則
- Open Closed Principle：軟件中的對象（類、模塊、函數等）應該對擴展開放，對修改關閉（勃蘭特·梅耶認爲，類只應該因錯誤而被修改）。也就是應該通過擴展來實現變化，而不是通過修改已有的代碼來實現改變。例如，現在業務需求有改變，所有書均打七折。有三個方法可以解決這個問題：第一種方法:修改接口。增加一個方法getOffPrice專門進行打折處理。第二種方法:修改實現類，在實現類裏修改getPrice方法。第三種方法:重新擴展一個類繼承NovelBook，重新複寫getPrice方法。根據對擴展開放對修改關閉原則我們應該選擇第三種解決方法。但實際開發中，修改原有代碼、擴展代碼（通過繼承的方式來升級、維護原有系統）往往是同時存在的。——開閉原則
這六大設計原則是以後學習設計模式的基礎，它們的共同目的就是 SOLID ——建立穩定、靈活、健壯的設計。
參考：
【1】重構·改善既有代碼的設計
【2】大話設計模式
【3】Android源碼設計模式解析與實戰