快捷導(dǎo)航

java設(shè)計(jì)模式--七大原則詳解

更新時間：2021年07月19日 16:23:22 作者：吾仄lo咚鏘

本篇文章主要對Java中的設(shè)計(jì)模式如，創(chuàng)建型模式、結(jié)構(gòu)型模式和行為型模式以及7大原則進(jìn)行了歸納整理，需要的朋友可以參考下,希望能給你帶來幫助

設(shè)計(jì)模式

軟件設(shè)計(jì)模式（Design pattern），又稱設(shè)計(jì)模式，是一套被反復(fù)使用、多數(shù)人知曉的、經(jīng)過分類編目的、代碼設(shè)計(jì)經(jīng)驗(yàn)的總結(jié)。使用設(shè)計(jì)模式是為了可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性、程序的重用性。

打個比方就像蓋大廈和小木屋，當(dāng)功能簡單，函數(shù)和代碼少時，我們能較輕松的直接上手；但如果是像大廈那樣，功能復(fù)雜，需求可能變化且代碼量大時，我們就不能直接上手就來，需要像建筑圖紙那樣提前規(guī)劃設(shè)計(jì)，那設(shè)計(jì)模式就像軟件(程序)的建筑圖紙。

設(shè)計(jì)模式的目的是為了讓軟件(程序)具有更好的：

1.代碼重用性

相同功能的代碼，不用多次編寫，降低冗余

2.可讀性

編程規(guī)范性, 便于其他程序員的閱讀和理解

3.可擴(kuò)展性

當(dāng)需要增加新的功能時，非常的方便，也稱為可維護(hù)性

4.可靠性

當(dāng)我們增加新的功能后，對原來的功能沒有影響

5.使程序呈現(xiàn)高內(nèi)聚，低耦合的特性

模塊內(nèi)部緊密，但模塊間依賴小，一者出錯不影響他者

單一職責(zé)原則

單一職責(zé)原則(Single responsibility principle)，即一個類應(yīng)該只負(fù)責(zé)一項(xiàng)職責(zé)。如類A負(fù)責(zé)兩個不同職責(zé)：職責(zé)1，職責(zé)2。當(dāng)職責(zé)1需求變更而改變A時，可能造成職責(zé)2執(zhí)行錯誤，所以需要將類A的粒度分解為A1、A2。

單一職責(zé)原則注意事項(xiàng)和細(xì)節(jié)

降低類的復(fù)雜度，一個類只負(fù)責(zé)一項(xiàng)職責(zé)。
提高類的可讀性，可維護(hù)性
降低變更引起的風(fēng)險(xiǎn)
通常情況下，我們應(yīng)當(dāng)遵守單一職責(zé)原則，只有邏輯足夠簡單，才可以在代碼級違反單一職責(zé)原則；只有類中方法數(shù)量足夠少，可以在方法級別保持單一職責(zé)原則

在這里插入圖片描述

接口隔離原則

接口隔離原則(Interface Segregation Principle)，即客戶端不應(yīng)該依賴它不需要的接口，即一個類對另一個類的依賴應(yīng)該建立在最小的接口上。

比如：類A通過接口 I I I依賴類B，類C通過接口 I I I依賴類D，如果接口 I I I對于類A和類C來說不是最小接口，那么類B和類D必須去實(shí)現(xiàn)他們不需要的方法。

在這里插入圖片描述

按隔離原則應(yīng)當(dāng)這樣處理：將接口 I I I拆分為獨(dú)立的幾個接口，將類分別與他們需要的接口建立依賴關(guān)系，也就是采用接口隔離原則。

在這里插入圖片描述

依賴倒轉(zhuǎn)原則

依賴倒轉(zhuǎn)原則(Dependence Inversion Principle)，依賴倒轉(zhuǎn)(倒置)的中心思想是面向接口編程，所謂“倒轉(zhuǎn)”是指抽象不應(yīng)該依賴細(xì)節(jié)，而是細(xì)節(jié)應(yīng)該依賴抽象。也就是高層模塊不應(yīng)該依賴低層模塊，二者都應(yīng)該依賴其抽象。因?yàn)橄鄬τ诩?xì)節(jié)的多變性，抽象的東西要穩(wěn)定的多。

比如有個Person類，可以接受Email、QQ和微信的消息。如果都為其提供一個專門的方法，就會讓代碼非常的冗余：

在這里插入圖片描述

可以引入一個IReceiver接口，讓Person類依賴該接口。這樣QQ、微信和Email各自實(shí)現(xiàn)IReceiver里面的方法即可：

在這里插入圖片描述

里氏替換原則

里氏替換原則(Liskov Substitution Principle)要求所有引用基類的地方必須能透明地使用其子類的對象。也就是在繼承關(guān)系中，子類盡量不要重寫父類的方法。繼承實(shí)際上讓兩個類耦合性增強(qiáng)了，特別是運(yùn)行多態(tài)比較頻繁的時，整個繼承體系的復(fù)用性會比較差。比如一種極端情況：一個類繼承了另一個類，但卻重寫了所有方法，那么繼承的意義何在？說好的復(fù)用呢？

在這里插入圖片描述

解決方法是把原來的父類和子類都繼承一個更通俗的基類，在適當(dāng)?shù)那闆r下，可以通過聚合，組合，依賴等來代替。

在這里插入圖片描述

開閉原則

開閉原則(Open Closed Principle)一個軟件實(shí)體如類，模塊和函數(shù)應(yīng)該對擴(kuò)展開放(對提供方)，對修改關(guān)閉(對使用方)。也就是當(dāng)軟件需要變化時，盡量通過擴(kuò)展軟件實(shí)體的行為來實(shí)現(xiàn)變化，而不是通過修改已有的代碼來實(shí)現(xiàn)變化。用抽象構(gòu)建框架，用實(shí)現(xiàn)擴(kuò)展細(xì)節(jié)。開閉原則是編程中最基礎(chǔ)、最重要的設(shè)計(jì)原則。編程中遵循其它原則，以及使用設(shè)計(jì)模式的目的就是遵循開閉原則。

舉個違反開閉原則的例子：

矩形Retangle和圓形Circle繼承了圖形類Shape（提供方），畫圖類GraphicEditor（使用方）會調(diào)用相關(guān)屬性。

在這里插入圖片描述

但是如果再新增一個三角形，就要在使用方GraphicEditor新增對應(yīng)方法，修改地方較多，違背開閉原則。

在這里插入圖片描述

改進(jìn)：把Shape做成抽象類并提供抽象方法draw，讓子類去實(shí)現(xiàn)即可。當(dāng)新增圖形種類時，只需讓新的圖形類繼承Shape，并實(shí)現(xiàn)draw方法即可。使用方的代碼就不需要修改，滿足開閉原則。

在這里插入圖片描述

迪米特法則

迪米特法則(Demeter Principle)又叫最少知道原則，即一個類對自己依賴的類知道的越少越好，核心是降低類之間的耦合。也就是說，對于被依賴的類不管多么復(fù)雜，都盡量將邏輯封裝在類的內(nèi)部。對外除了提供的public 方法，不對外泄露任何信息。避免與非直接朋友的耦合，只與直接的朋友通信，所謂的直接朋友是出現(xiàn)成員變量，方法參數(shù)，方法返回值中的類。而出現(xiàn)在局部變量中的類不是直接的朋友。也就是說，陌生的類最好不要以局部變量的形式出現(xiàn)在類的內(nèi)部。

比如有學(xué)院員工類和學(xué)校員工類，然后各有一個管理類有可以獲取其所有員工，學(xué)校員工管理類有方法打印全部員工。

在這里插入圖片描述

具體代碼：

void printAllEmployee(CollegeManager sub) {
		//獲取到學(xué)院員工
		List<CollegeEmployee> list1 = sub.getAllEmployee();
		System.out.println("---學(xué)院員工---");
		for (CollegeEmployee e : list1) {
			System.out.println(e.getId());
		}
		//獲取到學(xué)?？偛繂T工
		List<Employee> list2 = this.getAllEmployee();
		System.out.println("---學(xué)校員工---");
		for (Employee e : list2) {
			System.out.println(e.getId());
		}
	}

分析SchoolManager類，發(fā)現(xiàn)Employee和CollegeManager都是它的直接朋友（出現(xiàn)在參數(shù)和返回值中），但CollegeEmployee不是直接朋友，是以局部變量的形式，違背了迪米特原則。

改進(jìn)：避免依賴CollegeEmployee，封裝在CollegeManager中，對外提供public方法即可。

在這里插入圖片描述

void printAllEmployee(CollegeManager sub) {
		sub.printEmployee();
		//獲取到學(xué)校總部員工
		List<Employee> list2 = this.getAllEmployee();
		System.out.println("---學(xué)校員工---");
		for (Employee e : list2) {
			System.out.println(e.getId());
		}
	}