1、 單一職責原則：一個類只做它該做的事情
單一職責原則想表達的就是」高內聚」，寫代碼最終極的原則只有六個字」高內聚、低耦合」，就如同葵花寶典或闢邪劍譜的中心思想就八個字」欲練此功必先自宮」。
所謂的高內聚就是一個代碼模塊只完成一項功能，在面向對象中，如果只讓一個類完成它該做的事，而不涉及與它無關的領域就是踐行了高內聚的原則，這個類就只有單一職責。
我們都知道一句話叫」因為專注，所以專業」，一個對象如果承擔太多的職責，那麼註定它什麼都做不好。這個世界上任何好的東西都有兩個特徵，一個是功能單一，好的相機絕對不是電視購物裡面賣的那種一個機器有一百多種功能的，它基本上只能照相；另一個是模塊化，好的自行車是組裝車，從減震叉、剎車到變速器，所有的部件都是可以拆卸和重新組裝的，好的桌球拍也不是成品拍，一定是底板和膠皮可以拆分和自行組裝的，一個好的軟體系統，它裡面的每個功能模塊也應該是可以輕易的拿到其他系統中使用的，這樣才能實現軟體復用的目標。
2、開閉原則：軟體實體應當對擴展開放，對修改關閉
在理想的狀態下，當我們需要為一個軟體系統增加新功能時，只需要從原來的系統派生出一些新類就可以，不需要修改原來的任何一行代碼。
要做到開閉有兩個要點：
①、抽象是關鍵，一個系統中如果沒有抽象類或接口系統就沒有擴展點；
②、封裝可變性，將系統中的各種可變因素封裝到一個繼承結構中，如果多個可變因素混雜在一起，系統將變得複雜
3、依賴倒轉原則：面向接口編程
該原則說得直白一些就是聲明方法的參數類型、方法的返回類型、變量的引用類型時，儘可能使用抽象類型而不用具體類型，因為抽象類型可以被它的任何一個子類型所替代。
4、裡氏替換原則：任何時候都可以用子類型替換掉父類型
關於裡氏替換原則的描述，Barbara Liskov女士的描述比這個要複雜得多，但簡單的說就是能用父類型的地方就一定能使用子類型。
裡氏替換原則可以檢查繼承關係是否合理，如果一個繼承關係違背了裡氏替換原則，那麼這個繼承關係一定是錯誤的，需要對代碼進行重構。例如讓貓繼承狗，或者狗繼承貓，又或者讓正方形繼承長方形都是錯誤的繼承關係，因為你很容易找到違反裡氏替換原則的場景。
需要注意的是：子類一定是增加父類的能力而不是減少父類的能力，因為子類比父類的能力更多，把能力多的對象當成能力少的對象來用當然沒有任何問題。
5、接口隔離原則：接口要小而專，絕不能大而全
臃腫的接口是對接口的汙染，既然接口表示能力，那麼一個接口只應該描述一種能力，接口也應該是高度內聚的。
例如，琴棋書畫就應該分別設計為四個接口，而不應設計成一個接口中的四個方法，因為如果設計成一個接口中的四個方法，那麼這個接口很難用，畢竟琴棋書畫四樣都精通的人還是少數，而如果設計成四個接口，會幾項就實現幾個接口，這樣的話每個接口被復用的可能性是很高的。
Java中的接口代表能力、代表約定、代表角色，能否正確的使用接口一定是編程水平高低的重要標識。
6、合成聚合復用原則：優先使用聚合或合成關係復用代碼，儘量不要使用繼承。
要說明的是，即使在Java的API中也有不少濫用繼承的例子，例如Properties類繼承了Hashtable類，Stack類繼承了Vector類，這些繼承明顯就是錯誤的，更好的做法是在Properties類中放置一個Hashtable類型的成員並且將其鍵和值都設置為字符串來存儲數據，而Stack類的設計也應該是在Stack類中放一個Vector對象來存儲數據。
記住：任何時候都不要繼承工具類，工具是可以擁有並可以使用的，而不是拿來繼承的。
7、迪米特法則：迪米特法則又叫最少知識原則，一個對象應當對其他對象有儘可能少的了解
迪米特法則簡單的說就是如何做到"低耦合"，門面模式和調停者模式就是對迪米特法則的踐行。
對於門面模式可以舉一個簡單的例子，你去一家公司洽談業務，你不需要了解這個公司內部是如何運作的，你甚至可以對這個公司一無所知，去的時候只需要找到公司入口處的前臺美女，告訴她們你要做什麼，她們會找到合適的人跟你接洽，前臺的美女就是公司這個系統的門面。
再複雜的系統都可以為用戶提供一個簡單的門面，Java Web開發中作為前端控制器的Servlet或Filter不就是一個門面嗎，瀏覽器對伺服器的運作方式一無所知，但是通過前端控制器就能夠根據你的請求得到相應的服務。
調停者模式也可以舉一個簡單的例子來說明，例如一臺計算機，CPU、內存、硬碟、顯卡、音效卡各種設備需要相互配合才能很好的工作，但是如果這些東西都直接連接到一起，計算機的布線將異常複雜，在這種情況下，主板作為一個調停者的身份出現，它將各個設備連接在一起而不需要每個設備之間直接交換數據，這樣就減小了系統的耦合度和複雜度。
迪米特法則用通俗的話來將就是不要和陌生人打交道，如果真的需要，找一個自己的朋友，讓他替你和陌生人打交道。
歡迎朋友們關注轉發點讚，謝謝~~