前言
1. 單一職責原則 Single Responsibility Principle
- 1.1 基本介紹
- 1.2 單一職責原則注意事項和細節
- 1.3 一個示例
2. 介面隔離原則 Interface Segregation Principle
- 2.1 基本介紹
- 2.2 圖解
- 2.3 一個示例
3. 依賴倒轉(倒置)原則 Dependence Inversion Principle
- 3.1 基本介紹
- 3.2 依賴關系傳遞的三種方式及示例
  - 3.2.1 介面傳遞
  - 3.2.2 構造方法傳遞
  - 3.2.3 Setter方法傳遞
  - 3.2.4 呼叫上述方法
- 3.3 依賴倒轉原則的注意事項和細節
4. 里氏替換原則 Liskov Substitution Principle
- 4.1 OO中的繼承性的思考和說明
- 4.2 基本介紹
- 4.3 解決方法
- 4.4 一個示例
5. 開閉原則 Open Closed Principle
- 5.1 基本介紹
- 5.2 一個示例
6. 迪米特法則 Demeter Principle
- 6.1 基本介紹
- 6.2 迪米特法則注意事項和細節
- 6.3 一個示例
7. 合成復用原則 Composite Reuse Principle
- 7.1 基本介紹
8. 設計原則核心思想
最后

前言

資料來源：B站，尚硅谷Java設計模式；

1. 單一職責原則 Single Responsibility Principle

1.1 基本介紹

對類來說的，即一個類應該只負責一項職責，如類A負責兩個不同職責：職責1，職責2，
當職責1需求變更而改變A時，可能造成職責2執行錯誤，所以需要將類A的粒度分解為
A1，A2；

1.2 單一職責原則注意事項和細節

降低類的復雜度，一個類只負責一項職責；
提高類的可讀性，可維護性；
降低變更引起的風險；
通常情況下，我們應當遵守單一職責原則，只有邏輯足夠簡單，才可以在代碼級違反單一職責原則；只有類中方法數量足夠少，可以在方法級別保持單一職責原則；

1.3 一個示例

public class SingleResponsibility2 {
	public static void main(String[] args) {
		RoadVehicle roadVehicle = new RoadVehicle();
		roadVehicle.run("摩托車");
		roadVehicle.run("汽車");
		AirVehicle airVehicle = new AirVehicle();
		airVehicle.run("飛機");
	}
}

//方案分析
//1. 遵守單一職責原則
//2. 但是這樣做的改動很大，即將類分解，同時修改客戶端
//3. 改進：直接修改Vehicle 類，改動的代碼會比較少 => 方法級別保持單一
class RoadVehicle {
	public void run(String vehicle) {
		System.out.println(vehicle + "公路運行");
	}
}

class AirVehicle {
	public void run(String vehicle) {
		System.out.println(vehicle + "天空運行");
	}
}

class WaterVehicle {
	public void run(String vehicle) {
		System.out.println(vehicle + "水中運行");
	}
}

圖解：

原：只有Vehicle類，讓飛機在“公路運行”違反單一原則；
現：將Vehicle類拆分成三個類，各司其職；

2. 介面隔離原則 Interface Segregation Principle

2.1 基本介紹

客戶端不應該依賴它不需要的介面，即一個類對另一個類的依賴應該建立在最小的介面上；

2.2 圖解

未實作介面隔離

類A通過介面Interface1依賴類B，類C通過介面Interface1依賴類D，如果介面Interface1對于類A和類C來說不是最小介面，那么類B和類D必須去實作他們不需要的方法；

實作介面隔離

按隔離原則應當這樣處理：將介面Interface1拆分為獨立的幾個介面，類A和類C分別與他們需要的介面建立依賴關系，也就是采用介面隔離原則；

2.3 一個示例

public class Segregation1 {
	public static void main(String[] args) {
		A a = new A();
		a.depend1(new B()); // A類通過介面去依賴B類
		a.depend2(new B());
		a.depend3(new B());

		C c = new C();
		c.depend1(new D()); // C類通過介面去依賴(使用)D類
		c.depend4(new D());
		c.depend5(new D());
	}
}

// 介面1
interface Interface1 {
	void operation1();
}

// 介面2
interface Interface2 {
	void operation2();
	void operation3();
}

// 介面3
interface Interface3 {
	void operation4();
	void operation5();
}

class B implements Interface1, Interface2 {
	public void operation1() {
		System.out.println("B 實作了 operation1");
	}
	public void operation2() {
		System.out.println("B 實作了 operation2");
	}
	public void operation3() {
		System.out.println("B 實作了 operation3");
	}
}

class D implements Interface1, Interface3 {
	public void operation1() {
		System.out.println("D 實作了 operation1");
	}
	public void operation4() {
		System.out.println("D 實作了 operation4");
	}
	public void operation5() {
		System.out.println("D 實作了 operation5");
	}
}

// A 類通過介面Interface1,Interface2 依賴(使用) B類，但是只會用到1,2,3方法
class A { 
	public void depend1(Interface1 i) {
		i.operation1();
	}
	public void depend2(Interface2 i) {
		i.operation2();
	}
	public void depend3(Interface2 i) {
		i.operation3();
	}
}

// C 類通過介面Interface1,Interface3 依賴(使用) D類，但是只會用到1,4,5方法
class C { 
	public void depend1(Interface1 i) {
		i.operation1();
	}
	public void depend4(Interface3 i) {
		i.operation4();
	}
	public void depend5(Interface3 i) {
		i.operation5();
	}
}

圖解：

客戶端在定義dependX()方法時設定引數為介面型別，呼叫時傳遞介面的實作類作為引數；
介面間互不影響，是最小介面，實作相互隔離；

3. 依賴倒轉(倒置)原則 Dependence Inversion Principle

3.1 基本介紹

高層模塊不應該依賴低層模塊，二者都應該依賴其抽象；
抽象不應該依賴細節，細節應該依賴抽象；
依賴倒轉(倒置)的中心思想是面向介面編程；
依賴倒轉原則是基于這樣的設計理念：相對于細節的多變性，抽象的東西要穩定的多，以抽象為基礎搭建的架構比以細節為基礎的架構要穩定的多，在java中，抽象指的是介面或抽象類，細節就是具體的實作類；
使用介面或抽象類的目的是制定好規范，而不涉及任何具體的操作，把展現細節的任務交給他們的實作類去完成；

3.2 依賴關系傳遞的三種方式及示例

示例決議：將ITV介面的play()方法傳遞給IOpenAndClose介面的實作類OpenAndClose；

介面傳遞；
構造器傳遞；
Setter方法傳遞；

3.2.1 介面傳遞

//方式1: 通過介面傳遞實作依賴
//開關的介面
interface IOpenAndClose {
	public void open(ITV tv); //抽象方法,接收介面
}

//ITV介面
interface ITV { 
	public void play();
}

//實作介面[使用方]
class OpenAndClose implements IOpenAndClose {
	@Override
	public void open(ITV tv) {
		tv.play();
	}
}

3.2.2 構造方法傳遞

//方式2: 通過構造方法依賴傳遞
interface IOpenAndClose {
	public void open(); //抽象方法
}

//ITV介面
interface ITV { 
	public void play();
}

class OpenAndClose implements IOpenAndClose {
	public ITV tv; //成員

	public OpenAndClose(ITV tv) { //構造器
		this.tv = tv;
	}
	public void open() {
		this.tv.play();
	}
}

3.2.3 Setter方法傳遞

// 方式3: 通過setter方法傳遞
interface IOpenAndClose {
	public void open(); // 抽象方法
	public void setTv(ITV tv);
}

// ITV介面
interface ITV { 
	public void play();
}

class OpenAndClose implements IOpenAndClose {
	private ITV tv;

	public void setTv(ITV tv) {
		this.tv = tv;
	}
	public void open() {
		this.tv.play();
	}
}

3.2.4 呼叫上述方法

public class DependencyPass {
	public static void main(String[] args) {
		ChangHong changHong = new ChangHong();

		//通過介面進行依賴傳遞
		OpenAndClose openAndClose1 = new OpenAndClose();
		openAndClose1.open(changHong); //傳遞介面

		//通過構造器進行依賴傳遞
		OpenAndClose openAndClose2 = new OpenAndClose(changHong); //傳遞介面
		openAndClose2.open();

		//通過setter方法進行依賴傳遞
		OpenAndClose openAndClose3 = new OpenAndClose();
		openAndClose3.setTv(changHong); //傳遞介面
		openAndClose3.open();
	}
}

class ChangHong implements ITV {
	@Override
	public void play() {
		System.out.println("長虹電視機，打開");
	}
}

3.3 依賴倒轉原則的注意事項和細節

低層模塊盡量都要有抽象類或介面，或者兩者都有，程式穩定性更好；
變數的宣告型別盡量是抽象類或介面，這樣我們的變數參考和實際物件間，就存在一個緩沖層，利于程式擴展和優化；
繼承時遵循里氏替換原則；

4. 里氏替換原則 Liskov Substitution Principle

4.1 OO中的繼承性的思考和說明

繼承包含這樣一層含義：父類中凡是已經實作好的方法，實際上是在設定規范和契約，雖然它不強制要求所有的子類必須遵循這些契約，但是如果子類對這些已經實作的方法任意修改，就會對整個繼承體系造成破壞；
繼承在給程式設計帶來便利的同時，也帶來了弊端，比如使用繼承會給程式帶來侵入性，程式的可移植性降低，增加物件間的耦合性，如果一個類被其他的類所繼承，則當這個類需要修改時，必須考慮到所有的子類，并且父類修改后，所有涉及到子類的功能都有可能產生故障；
問題提出：在編程中，如何正確的使用繼承？答：里氏替換原則；

4.2 基本介紹

里氏替換原則(Liskov Substitution Principle)在1988年，由麻省理工學院的以為姓里
的女士提出的；
如果對每個型別為T1的物件o1，都有型別為T2的物件o2，使得以T1定義的所有程式P在所有的物件o1都代換成o2時，程式P的行為沒有發生變化，那么型別T2是型別T1的子型別，換句話說，所有參考基類的地方必須能透明地使用其子類的物件；
在使用繼承時，遵循里氏替換原則，在子類中盡量不要重寫父類的方法；
里氏替換原則告訴我們，繼承實際上讓兩個類耦合性增強了，在適當的情況下，可
以通過聚合、組合、依賴來解決問題；

4.3 解決方法

通用的做法是：原來的父類和子類都繼承一個更通俗的基類，原有的繼承關系去掉，
采用依賴，聚合，組合等關系代替；

4.4 一個示例

public class Liskov {
	public static void main(String[] args) {
		A a = new A();
		System.out.println("11-3=" + a.func1(11, 3));
		System.out.println("-----------------------");
		
		B b = new B();
		System.out.println("11+3=" + b.func1(11, 3));//這里本意是求出11+3
		System.out.println("11+3+9=" + b.func2(11, 3));

		//使用組合仍然可以使用到A類相關方法
		System.out.println("11-3=" + b.func3(11, 3));// 這里本意是求出11-3
	}
}

//基類，可以把更加基礎的方法和成員寫到Base類
class Base {
}

//A類
class A extends Base {
	//回傳兩個數的差
	public int func1(int num1, int num2) {
		return num1 - num2;
	}
}

//B類
class B extends Base {
	//如果B需要使用A類的方法,使用組合關系
	private A a = new A();
	
	//這里重寫了A類的方法, 可能是無意識
	public int func1(int a, int b) {
		return a + b;
	}
	public int func2(int a, int b) {
		return func1(a, b) + 9;
	}
	//我們仍然想使用A的方法
	public int func3(int a, int b) {
		return this.a.func1(a, b);
	}
}

圖解：

原：B類繼承A類，B類重寫A類的func1()方法，在呼叫func1()時容易引起歧義；
現：B類和A類共同繼承一個Base基類，B類可以通過組合的方式使用A類的方法；

5. 開閉原則 Open Closed Principle

5.1 基本介紹

開閉原則（Open Closed Principle）是編程中最基礎、最重要的設計原則；
一個軟體物體如類，模塊和函式應該對擴展開放(對提供方)，對修改關閉(對使用方)，用抽象構建框架，用實作擴展細節；
當軟體需要變化時，盡量通過擴展軟體物體的行為來實作變化，而不是通過修改已有的代碼來實作變化；
編程中遵循其它原則，以及使用設計模式的目的就是遵循開閉原則；

5.2 一個示例

public class Ocp {
	public static void main(String[] args) {
		//模擬客戶端邏輯
		GraphicEditor graphicEditor = new GraphicEditor();
		graphicEditor.drawShape(new Rectangle());
		graphicEditor.drawShape(new Circle());
	}
}

//用于繪圖的類 [使用方]
class GraphicEditor {
	//接收Shape物件，呼叫draw方法
	public void drawShape(Shape s) {
		s.draw();
	}
}

//Shape類，基類
abstract class Shape {
	int m_type;
	public abstract void draw();//抽象方法
}

//矩形
class Rectangle extends Shape {
	Rectangle() {
		super.m_type = 1;
	}
	@Override
	public void draw() {
		System.out.println(" 繪制矩形 ");
	}
}

//新增圓形
class Circle extends Shape {
	Circle() {
		super.m_type = 2;
	}
	@Override
	public void draw() {
		System.out.println(" 繪制圓形 ");
	}
}

圖解：

原：在使用方GraphicEditor類里通過if-else方式判斷m_type的屬性，呼叫drawXxx()方法，這樣在新增圖形時要修改if-else判斷和新增drawXxx()方法；
現：將drawXxx()方法下放到圖形，在新增圖形時，使用方GraphicEditor類不用做任何修改；
有點類似于依賴倒轉原則的介面傳遞依賴，只不過這里的drawShape()方法使用超類Shape作為引數，而這兩種方式在進行擴展時都不需要對使用方進行更改；

6. 迪米特法則 Demeter Principle

6.1 基本介紹

一個物件應該對其他物件保持最少的了解；
類與類關系越密切，耦合度越大；
迪米特法則(Demeter Principle)又叫最少知道原則，即一個類對自己依賴的類知道的越少越好，也就是說，對于被依賴的類不管多么復雜，都盡量將邏輯封裝在類的內部，對外除了提供的public 方法，不對外泄露任何資訊；
迪米特法則還有個更簡單的定義：只與直接的朋友通信；
直接的朋友：每個物件都會與其他物件有耦合關系，只要兩個物件之間有耦合關系，我們就說這兩個物件之間是朋友關系，耦合的方式很多，依賴，關聯，組合，聚合等，其中，我們稱出現成員變數，方法引數，方法回傳值中的類為直接的朋友，而出現在區域變數中的類不是直接的朋友，也就是說，陌生的類最好不要以區域變數的形式出現在類的內部；

6.2 迪米特法則注意事項和細節

迪米特法則的核心是降低類之間的耦合；
但是注意：由于每個類都減少了不必要的依賴，因此迪米特法則只是要求降低類間(物件間)耦合關系，并不是要求完全沒有依賴關系；

6.3 一個示例

要求：呼叫schoolManager類里的printAllEmployee()方法能把學院和學校總部的員工資訊都輸出；

public class Demeter1 {
	public static void main(String[] args) {
		SchoolManager schoolManager = new SchoolManager();
		//輸出學院的員工id和學校總部的員工資訊
		schoolManager.printAllEmployee(new CollegeManager());
	}
}

//學校總部員工類
class Employee {
	private String id;
	public void setId(String id) {
		this.id = id;
	}
	public String getId() {
		return id;
	}
}

//學院的員工類
class CollegeEmployee {
	private String id;
	public void setId(String id) {
		this.id = id;
	}
	public String getId() {
		return id;
	}
}

//學院員工的管理類
class CollegeManager {
	//回傳學院的所有員工
	public List<CollegeEmployee> getAllEmployee() {
		List<CollegeEmployee> list = new ArrayList<CollegeEmployee>();
		for (int i = 0; i < 10; i++) { //這里我們增加了10個員工到 list
			CollegeEmployee emp = new CollegeEmployee();
			emp.setId("學院員工id= " + i);
			list.add(emp);
		}
		return list;
	}
	//輸出學院員工的資訊
	public void printEmployee() {
		List<CollegeEmployee> list1 = getAllEmployee();
		System.out.println("------------學院員工------------");
		for (CollegeEmployee e : list1) {
			System.out.println(e.getId());
		}
	}
}

//學校員工的管理類
class SchoolManager {
	//回傳學校總部的員工
	public List<Employee> getAllEmployee() {
		List<Employee> list = new ArrayList<Employee>();
		for (int i = 0; i < 5; i++) { //這里我們增加了5個員工到 list
			Employee emp = new Employee();
			emp.setId("學校總部員工id= " + i);
			list.add(emp);
		}
		return list;
	}
	//該方法完成輸出學校總部和學院員工資訊(id)
	void printAllEmployee(CollegeManager sub) {
		//將輸出學院的員工方法，封裝到CollegeManager，即可直接呼叫printEmployee()方法
		sub.printEmployee();
		//獲取到學校總部員工
		List<Employee> list2 = this.getAllEmployee();
		System.out.println("------------學校總部員工------------");
		for (Employee e : list2) {
			System.out.println(e.getId());
		}
	}
}

圖解：

原：sub.printEmployee()的實作邏輯在SchoolManager管理類里；
現：該方法的實作在CollegeManager管理類里，SchoolManager不必知道CollegeManager的實作邏輯；

7. 合成復用原則 Composite Reuse Principle

7.1 基本介紹

合成復用原則（Composite Reuse Principle）是盡量使用合成/聚合的方式，而不是使用繼承；

合成復用原則

8. 設計原則核心思想

找出應用中可能需要變化之處，把它們獨立出來，不要和那些不需要變化的代碼混在一起；
針對介面編程，而不是針對實作編程；
為了互動物件之間的松耦合設計而努力；

最后

新人制作，如有錯誤，歡迎指出，感激不盡！歡迎關注公眾號，會分享一些更日常的東西！如需轉載，請標注出處！

轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/308462.html

標籤：設計模式

上一篇：設計模式——簡單工廠模式

下一篇：微服務拆分原則以及實踐

設計模式 | 第1章 設計模式的七大原則

前言

1. 單一職責原則 Single Responsibility Principle

1.1 基本介紹

1.2 單一職責原則注意事項和細節

1.3 一個示例

2. 介面隔離原則 Interface Segregation Principle

2.1 基本介紹

2.2 圖解

2.3 一個示例

3. 依賴倒轉(倒置)原則 Dependence Inversion Principle

3.1 基本介紹

3.2 依賴關系傳遞的三種方式及示例

3.2.1 介面傳遞

3.2.2 構造方法傳遞

3.2.3 Setter方法傳遞

3.2.4 呼叫上述方法

3.3 依賴倒轉原則的注意事項和細節

4. 里氏替換原則 Liskov Substitution Principle

4.1 OO中的繼承性的思考和說明

4.2 基本介紹

4.3 解決方法

4.4 一個示例

5. 開閉原則 Open Closed Principle

5.1 基本介紹

5.2 一個示例

6. 迪米特法則 Demeter Principle

6.1 基本介紹

6.2 迪米特法則注意事項和細節

6.3 一個示例

7. 合成復用原則 Composite Reuse Principle

7.1 基本介紹

8. 設計原則核心思想

最后

設計模式 | 第1章設計模式的七大原則