java中的"六原則一法則"
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、記憶體、硬碟、顯示卡、音效卡各種裝置需要相互配合才能很好的工作，但是如果這些東西都直接連線到一起，計算機的佈線將異常複雜，在這種情況下，主機板作為一個調停者的身份出現，它將各個裝置連線在一起而不需要每個裝置之間直接交換資料，這樣就減小了系統的耦合度和複雜度。