本文源碼：GitHub·點這里 || GitEE·點這里

文章目錄

• 一、單一職責原則
• 二、接口隔離原則
• 三、依賴倒轉原則
• 四、里氏替換原則
• 五、開閉原則
• 六、迪米特原則
• 七、設計原則總結
• 八、源代碼地址

一、單一職責原則

1、概念描述

對類來說的，即一個類應該只負責一項職責。如果一個類負責兩個職責，可能存在職責1變化，引起職責2變化的情況。可以基于抽象邏輯，或者業務邏輯對類進行細化。

2、案例演示

這里基于方法和類的細化都可以，可以根據實際業務選擇。

class Animal {public void dogVoice (){System.out.println("狗叫聲：旺旺");}public void cowVoice (){System.out.println("牛叫聲：哞哞");} } class DogVoice {public String getDogVoice (){return "旺旺" ;} } class CowVoice {public String getCowVoice (){return "哞哞" ;} }

3、注意事項

減少代碼一處變更引起的程序大規模改動情況，降低類的復雜度，提高類的可讀性，可維護性。通常情況下，需要遵守單一職責原則，可以適當違反單一職責原則。

二、接口隔離原則

1、概念描述

客戶端不應該依賴它不需要的接口，一個類對另一個類的依賴，應該建立在最小的接口上。

2、案例演示

interface ReadBlog {String getBlog () ; } interface AdminBlog {Boolean insertBlog () ;Boolean updateBlog () ;Boolean deleteBlog () ; } /*** 讀者只開放博客閱讀接口*/ class Reader implements ReadBlog {@Overridepublic String getBlog() {return null;} } /*** 管理員有博客全部的管理權限*/ class AdminUser implements AdminBlog,ReadBlog {@Overridepublic String getBlog() {return null;}@Overridepublic Boolean insertBlog() {return null;}@Overridepublic Boolean updateBlog() {return null;}@Overridepublic Boolean deleteBlog() {return null;} }

3、注意事項

接口的設計粒度越小，則應用系統程序越靈活，程序變得靈活也就意味同時結構復雜性提高，開發開發和理解的難度也會變大，可維護性降低。

三、依賴倒轉原則

1、概念描述

高層模塊不應該依賴低層模塊，兩者應依賴其抽象；抽象不應該依賴細節，細節應該依賴抽象；中心思想是面向接口編程。

2、案例演示

public class C01_FarmFactory {public static void main(String[] args) {Animal animal = new Dog() ;FarmFactory farm = new Farming() ;farm.breed(animal) ;animal = new Pig() ;farm.breed(animal) ;} } /*** 接口聲明依賴對象*/ interface FarmFactory {void breed (Animal animal) ; } class Farming implements FarmFactory {@Overridepublic void breed(Animal animal) {System.out.println("農場飼養："+animal.getAnimalName());} } interface Animal {String getAnimalName () ; } class Dog implements Animal {@Overridepublic String getAnimalName() {return "牧羊犬";} } class Pig implements Animal {@Overridepublic String getAnimalName() {return "土豬一號";} }

3、注意事項

相對于系統開發的多變性，抽象的相對穩定。以抽象為基礎搭建的架構比以細節為基礎的架構要穩定靈活。下層模塊盡量都要有抽象類或接口，程序穩定性更好。變量的聲明類型盡量是抽象類或接口,這樣變量引用和實際對象之間存在一個過渡空間，利于程序擴展和優化。

四、里氏替換原則

1、概念描述

假設如下場景：

• 存在，一個類型T1，和實例的對象O1
• 存在，一個類型T2，和實例的對象O2

如果將所有類型為T1的對象O1都替換成類型T2的對象O2，程序的行為不發生改變。那么類型T2是類型T1的子類型。換句話說，所有引用基類的地方必須能透明地使用其子類的對象。

2、案例演示

public class C01_Calculate {public static void main(String[] args) {BizCalculate bizCalculate = new BizCalculate() ;System.out.println(bizCalculate.add(2,3));} } class Calculate { } class BaseCalculate extends Calculate {public int add (int a,int b){return a+b;} } /*** 這里使用組合的方式完成計算*/ class BizCalculate extends Calculate {private BaseCalculate baseCalculate = new BaseCalculate() ;public int add (int a,int b){return this.baseCalculate.add(a,b);} }

3、注意事項

使用繼承時，遵循里氏替換原則，在子類中盡量不要重寫父類的方法;子類可以擴展父類的功能，但不能改變原有父類的功能；在適當的情況下，可以通過聚合，組合，依賴等方式解決問題。

五、開閉原則

1、概念描述

開閉原則是編程中最基礎、最重要的設計原則，在代碼結構的設計設計時，應該考慮對擴展開放，對修改關閉，抽象思維搭建結構，具體實現擴展細節。

2、案例演示

public class C01_BookPrice {public static void main(String[] args) {ParityBook parityBook = new DiscountBook("Java",100.00) ;System.out.println(parityBook.getPrice());} } interface Book {String getName () ;Double getPrice () ; } /*** 平價書籍*/ class ParityBook implements Book {private String name ;private Double price ;public ParityBook(String name, Double price) {this.name = name;this.price = price;}@Overridepublic String getName() {return this.name ;}@Overridepublic Double getPrice() {return this.price ;} } /*** 打折數據擴展價格計算策略*/ class DiscountBook extends ParityBook {public DiscountBook(String name, Double price) {super(name, price);}@Overridepublic Double getPrice() {double oldPrice = super.getPrice();return oldPrice * 0.8 ;} }

3、注意事項

基于開閉原則設計的代碼結構可以提高復用性和可維護性，通過接口或抽象類可以約束類的變化行為，基于指定策略對變化行為進行封裝，并且能夠實現對擴展開放，使用設計模式的基本原則就是遵循開閉原則。

六、迪米特原則

1、概念描述

迪米特原則又叫最少知道原則，即一個類對自己依賴的類知道的越少越好。也就是說，對于被依賴的類不管多么復雜，都盡量將邏輯封裝在類的內部。對外除了提供的public方法，不對外開放任何信息。類與類關系越密切，耦合度越大，耦合的方式很多，依賴，關聯，組合，聚合等。

• 直接朋友概念

兩個對象之間有耦合關系，就說這兩個對象之間是朋友關系。其中出現成員變量，方法參數，方法返回值中的類稱為直接朋友，而出現在局部變量中的類不是直接朋友。從原則上說，陌生的類最好不要以局部變量的形式出現在類的內部。

2、案例演示

public class C01_Employee {public static void main(String[] args) {HeadCompanyEmpManage empManage = new HeadCompanyEmpManage() ;BranchCompanyEmpManage branchEmp = new BranchCompanyEmpManage() ;empManage.printEmp(branchEmp);} } /*** 總公司員工*/ class HeadCompanyEmp {public String name ;public HeadCompanyEmp(String name) {this.name = name;}@Overridepublic String toString() {return "HeadCompanyEmp{name='" + name + '}';} } /*** 分公司員工*/ class BranchCompanyEmp {public String name ;public BranchCompanyEmp(String name) {this.name = name;}@Overridepublic String toString() {return "BranchCompanyEmp{name='" + name + '}';} } /*** 分公司員工管理*/ class BranchCompanyEmpManage {// 添加分公司員工public List<BranchCompanyEmp> addEmp (){List<BranchCompanyEmp> list = new ArrayList<>() ;for (int i = 1 ; i <= 3 ; i++){list.add(new BranchCompanyEmp("分公司員工"+i)) ;}return list ;}// 獲取分公司員工public void printBranchCompanyEmp (){List<BranchCompanyEmp> list = addEmp () ;for (BranchCompanyEmp emp:list){System.out.println(emp);}} } /*** 總公司員工管理,基于迪米特原則,不出現陌生類*/ class HeadCompanyEmpManage {// 添加總公司員工public List<HeadCompanyEmp> addHeadEmp (){List<HeadCompanyEmp> list = new ArrayList<>() ;for (int i = 1 ; i <= 3 ; i++){list.add(new HeadCompanyEmp("總公司員工"+i)) ;}return list ;}public void printEmp (BranchCompanyEmpManage empManage){// 打印分公司員工empManage.printBranchCompanyEmp();List<HeadCompanyEmp> headEmpList = addHeadEmp () ;for (HeadCompanyEmp headCompanyEmp:headEmpList){System.out.println(headCompanyEmp);}} }

3、注意事項

迪米特原則的初衷是降低類之間的耦合，由于每個類都減少了不必要的依賴，因此可以降低耦合關系。降低耦合關系，并不是要求完全沒有依賴關系，過度的使用迪米特原則，容易產生大量的中間類，導致復雜度變大。所以在使用迪米特原則時要根據實際業務權衡。

七、設計原則總結

設計模式和設計原則的核心思想都是：判斷業務應用中可能會變化模塊，并且把這些模塊獨立出來，基于指定的策略進行封裝，不要和那些變化的不大的模塊耦合在一起，封裝思想上基于接口和抽象類，而不是針對具體的實現編程。核心目的就是降低交互對象之間的松耦合度。設計模式和原則都不是可以生搬硬套的公式，個人理解：只要形似，神韻就自然不差。

八、源代碼地址

GitHub·地址 https://github.com/cicadasmile/model-arithmetic-parent GitEE·地址 https://gitee.com/cicadasmile/model-arithmetic-parent

總結

以上是生活随笔為你收集整理的软件工程六大设计原则总结，案例演示的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。