java中的"六原則一法則"

1.單一職責原則

一個類只作它該作的事情。

單一職責原則想表達的就是"高內聚"，寫代碼最終極的原則只有六個字"高內聚、低耦合"，所謂的高內聚就是一個代碼模塊只完成一項功能，在面向對象中，若是隻讓一個類完成它該作的事，而不涉及與它無關的領域就是踐行了高內聚的原則，這個類就只有單一職責。另外一個是模塊化，好的自行車是組裝車，從減震叉、剎車到變速器，全部的部件都是能夠拆卸和從新組裝的，好的乒乓球拍也不是成品拍，必定是底板和膠皮能夠拆分和自行組裝的，一個好的軟件系統，它裏面的每一個功能模塊也應該是能夠輕易的拿到其餘系統中使用的，這樣才能實現軟件複用的目標。說簡單點就是分工明確，各司其職。

2.開閉原則

軟件實體應當對擴展開放，對修改關閉。

在理想的狀態下，當咱們須要爲一個軟件系統增長新功能時，只須要從原來的系統派生出一些新類就能夠，不須要修改原來的任何一行代碼。 要作到開閉有兩個要點：

1. 抽象是關鍵，一個系統中若是沒有抽象類或接口，系統就沒有擴展點；

2. 封裝可變性，將系統中的各類可變因素封裝到一個繼承結構中，若是多個可變因素混雜在一塊兒，系統將變得複雜而換亂，若是不清楚如何封裝可變性，能夠參考《設計模式精解》一書中對橋樑模式的講解的章節。

3.依賴倒轉原則

面向接口編程，多態。

該原則說得直白和具體一些就是聲明方法的參數類型、方法的返回類型、變量的引用類型時，儘量使用抽象類型而不用具體類型，由於抽象類型能夠被它的任何一個子類型所替代，請參考下面的里氏替換原則。 參考博客

4.里氏替換原則

任什麼時候候均可以用子類型替換掉父類型。

關於里氏替換原則的描述，Barbara Liskov女士的描述比這個要複雜得多，但簡單的說就是能用父類型的地方就必定能使用子類型。里氏替換原則能夠檢查繼承關係是否合理，若是一個繼承關係違背了里氏替換原則，那麼這個繼承關係必定是錯誤的，須要對代碼進行重構。例如讓貓繼承狗，或者狗繼承貓，又或者讓正方形繼承長方形都是錯誤的繼承關係，由於你很容易找到違反里氏替換原則的場景。須要注意的是：子類必定是增長父類的能力而不是減小父類的能力，由於子類比父類的能力更多，把能力多的對象當成能力少的對象來用固然沒有任何問題。

5.接口隔離原則

接口要小而專，毫不能大而全。

臃腫的接口是對接口的污染，既然接口表示能力，那麼一個接口只應該描述一種能力，接口也應該是高度內聚的。例如，琴棋書畫就應該分別設計爲四個接口，而不該設計成一個接口中的四個方法，由於若是設計成一個接口中的四個方法，那麼這個接口很難用，畢竟琴棋書畫四樣都精通的人仍是少數，而若是設計成四個接口，會幾項就實現幾個接口，這樣的話每一個接口被複用的可能性是很高的。Java中的接口表明能力、表明約定、表明角色，可否正確的使用接口必定是編程水平高低的重要標識。

6.合成聚合複用原則

優先使用聚合或合成關係複用代碼。

經過繼承來複用代碼是面向對象程序設計中被濫用得最多的東西，由於全部的教科書都無一例外的對繼承進行了鼓吹從而誤導了初學者，類與類之間簡單的說有三種關係，Is-A關係、Has-A關係、Use-A關係，分別表明繼承、關聯和依賴。其中，關聯關係根據其關聯的強度又能夠進一步劃分爲關聯、聚合和合成，但說白了都是Has-A關係，合成聚合複用原則想表達的是優先考慮Has-A關係而不是Is-A關係複用代碼，緣由嘛,能夠本身從百度上找到一萬個理由，須要說明的是，即便在Java的API中也有很多濫用繼承的例子，例如Properties類繼承了Hashtable類，Stack類繼承了Vector類，這些繼承明顯就是錯誤的，更好的作法是在Properties類中放置一個Hashtable類型的成員而且將其鍵和值都設置爲字符串來存儲數據，而Stack類的設計也應該是在Stack類中放一個Vector對象來存儲數據。

記住：任什麼時候候都不要繼承工具類，工具是能夠擁有並可使用的，而不是拿來繼承的。

7.迪米特法則

迪米特法則又叫最少知識原則，一個對象應當對其餘對象有儘量少的瞭解。

再複雜的系統均可覺得用戶提供一個簡單的門面，Java Web開發中做爲前端控制器的Servlet或Filter不就是一個門面嗎，瀏覽器對服務器的運做方式一無所知，可是經過前端控制器就可以根據你的請求獲得相應的服務。調停者模式也能夠舉一個簡單的例子來講明，例如一臺計算機，CPU、內存、硬盤、顯卡、聲卡各類設備須要相互配合才能很好的工做，可是若是這些東西都直接鏈接到一塊兒，計算機的佈線將異常複雜，在這種狀況下，主板做爲一個調停者的身份出現，它將各個設備鏈接在一塊兒而不須要每一個設備之間直接交換數據，這樣就減少了系統的耦合度和複雜度。

原文：zero.osai.club/java/2019/0…