1.單一職責原則(Single Responsibility Principle)
也就是職責劃分要明確，單一職責原則提出了一個撰寫程式的標準，用“職責”或者“變化原因”來衡量介面或者類設計的是否優良，但是“職責”或者“變化原因”都是不可度量的，因專案而異，因環境而異，
介面一定要做到單一職責，類的設計盡量做到只有一個原因引起變化，
2.里氏替換原則(Liskov Substitution Principle)
java三大特征：封裝、繼承、多型
該原則主要針對繼承這一關系，
通俗點講就是:只要父類能出現的地方子類就可以出現，而且替換為子類也不會產生任何錯誤和例外，使用者根本不需要知道是父類還是子類，但是，反過來就不行，有子類的地方，父類未必就能適應，
規范:
- 子類必須完全實作父類的方法
- 子類可以有自己的個性
- 覆寫或實作父類的方法是輸入引數可以被放大，子類中的方法的引數必須與超類中被重寫的方法的引數相同或者更寬松(注意多載和重寫這兩個概念)
- 重寫或實作父類的方法時輸出結果可以被縮小(return<=)
采用里氏替換原則時，盡量避免子類的“個性”，一旦子類有“個性”，這個子類和父類之間的關系就很難調和了
3.依賴倒置原則(Dependence Inversion Principle)
即面向介面編程，傳值直接使用介面或者抽象類
規范:
1.每個類盡量都有介面或抽象類，或者抽象類和介面兩者都具備
2.變數的表面型別盡量是介面或者抽象類
3.任何類都不應該從具體類派生
4.盡量不要重寫基類的方法
5.結合里氏替換原則使用
4.介面隔離原則(Interface Segregation Principle)
何為介面:1.實體介面(new關鍵字產生一個實體)；2.類介面(interface關鍵字定義的介面)
該原則就是將介面的職責細分，保證介面的純潔性:
1.介面盡量小(不能違反單一職責原則)
2.介面要高內聚(提高介面、類、模塊的處理能力，減少對外的互動，也就是你只用知道結果就好，不用管它是怎么實作的)
3.定制服務(根據客戶端來劃分介面,按照權限劃分介面)
4.介面設計是有限度的(無標準視情況而定)
實踐中的規則:
1.一個介面只服務于一個子模塊或者業務邏輯
2.通過業務邏輯壓縮介面中的public方法，介面要時常去回顧，盡量讓介面達到“最小”，而不是“臃腫”的一大堆方法
3.已經被污染的介面，盡量去修改，若變更的風險較大，則采用配接器模式進行轉化處理
4.視情況而定，不用盲目抄襲
5.迪米特爾法則(Law of Demeter Principle || 最少知道原則)
直接的朋友:成員變數、方法引數、方法回傳值
只和直接的朋友交流，陌生的類最好不用以區域變數的方式出現在類的內部，盡量少對外公布public方法和非靜態的public變數，如果一個方法放在本類中，既不增加類間關系，也不對本類產生負面影響，那就放置在本類，(類間解耦，弱耦合)
6.開閉原則(Open Closed Principle)
java世界中最基礎的設計原則，他指導我們如何創建一個穩定的、靈活的系統
此時有一個需求書店打9折促銷，面對需求變化，我們一般有三種解決辦法:
1.修改介面(不可行)
2.修改實作類(不是最優)
3.通過拓展實作變化(好辦法)：增加一個子類去重寫getPrince方法，通過這個拓展類來產生新的物件，實作業務變化對系統的最小化開發
變化的三種型別:
1.邏輯變化(只變化一個邏輯，而不涉及其他模塊)
2.子模塊變化(一個模塊變化，會對其他的模塊產生影響)
3.可見視圖變化(如jsp程式、Swing界面)
開閉原則規范:
1.抽象規范:a.通過介面或者抽象類進行約束拓展，對拓展進行邊界限定，不允許出現在介面或抽象類不存在的public方法;b.引數型別、參考物件盡量使用介面或者抽象類，而不是具體實作類;c.抽象類要保持穩定，一旦確定即不允許更改
2.使用元資料控制模塊行為:
元資料:用來描述環境和資料的資料，通俗地來講就是配置引數，引數可以從檔案中得，也可以從資料庫中獲得，
一句話“約定大于配置，配置大于代碼”，約定：就是各種約束檔案；配置：就是各種xml檔案配置；代碼：手敲的代碼
3.制定專案章程
4.封裝變化:a.將相同的變化封裝當一個介面或者抽象類中；b.將不同的變化封裝到不同的介面或者抽象類中，不應該有兩個不同的變化出現在同一介面或者抽象類中(類似手機:不同的品牌，不同的廠商....)
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/102089.html
標籤：Java