2. 程式人生 > 實用技巧 >第 2 章 設計模式七大原則

第 2 章 設計模式七大原則

阿新 • • 發佈：2020-08-11

目錄

2.1 設計模式的目的

編寫軟體過程中，程式設計師面臨著來自耦合性，內聚性以及可維護性，可擴充套件性，重用性，靈活性等多方面的挑戰，設計模式是為了讓程式(軟體)具有更好：

  1. 程式碼重用性 (即：相同功能的程式碼，不用多次編寫)
  2. 可讀性 (即：程式設計規範性，便於其他程式設計師的閱讀和理解)
  3. 可擴充套件性 (即：當需要增加新的功能時，非常的方便，稱為可維護)
  4. 可靠性 (即：當我們增加新的功能後，對原來的功能沒有影響)
  5. 使程式呈現高內聚，低耦合的特性

設計模式包含了面向物件的精髓，“懂了設計模式，你就懂了面向物件分析和設計（OOA/D）的精要”

2.2 設計模式七大原則

設計模式原則，其實就是程式設計師在程式設計時，應當遵守的原則，也是各種設計模式的基礎(即：設計模式為什麼這樣設計的依據)。

設計模式常用的七大原則有:

  1. 單一職責原則
  2. 介面隔離原則
  3. 依賴倒轉(倒置)原則
  4. 里氏替換原則
  5. 開閉原則
  6. 迪米特法則
  7. 合成複用原則

2.3 單一職責原則

2.3.1 基本介紹

  對類來說的，即一個類應該只負責一項職責

。如類 A 負責兩個不同職責：職責 1，職責 2。當職責 1 需求變更而改變 A 時，可能造成職責 2 執行錯誤，所以需要將類 A 的粒度分解為 A1，A2。

2.3.2 應用例項

交通工具案例

方案 1

package com.atguigu.principle.singleresponsibility;

public class SingleResponsibility1 {

	public static void main(String[] args) {
		Vehicle vehicle = new Vehicle();
		vehicle.run("摩托車");
		vehicle.run("汽車");
		vehicle.run("飛機"); // (有誤)飛機 在公路上執行....
	}
}

class Vehicle {
	public void run(String vehicle) {
		System.out.println(vehicle + " 在公路上執行....");
	}
}

  1. 在方式 1 的 run 方法中，違反了單一職責原則

  2. 解決的方案非常的簡單，根據交通工具執行方法不同，分解成不同類即可


方案 2

package com.atguigu.principle.singleresponsibility;

public class SingleResponsibility2 {

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

}

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 + "水中執行");
	}
}

  1. 遵守單一職責原則

  2. 但是這樣做的改動很大，即將類分解，同時修改客戶端

  3. 改進：直接修改 Vehicle 類，改動的程式碼會比較少 => 方案 3


方案 3

package com.atguigu.principle.singleresponsibility;

public class SingleResponsibility3 {

	public static void main(String[] args) {
		// TODO Auto-generated method stub
		Vehicle2 vehicle2  = new Vehicle2();
		vehicle2.run("汽車");
		vehicle2.runWater("輪船");
		vehicle2.runAir("飛機");
	}

}

class Vehicle2 {
	public void run(String vehicle) {
		System.out.println(vehicle + " 在公路上執行....");
	}
	
	public void runAir(String vehicle) {
		System.out.println(vehicle + " 在天空上執行....");
	}
	
	public void runWater(String vehicle) {
		System.out.println(vehicle + " 在水中行....");
	}
}

  1. 這種修改方法沒有對原來的類做大的修改，只是增加方法。

  2. 這裡雖然沒有在類這個級別上遵守單一職責原則，但是在方法級別上，仍然是遵守單一職責。

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

  • 降低類的複雜度，一個類只負責一項職責。

  • 提高類的可讀性，可維護性。

  • 降低變更引起的風險。

  • 通常情況下，應當遵守單一職責原則，只有邏輯足夠簡單，才可以在程式碼級違反單一職責原則；只有類中方法數量足夠少，可以在方法級別保持單一職責原則

2.4 介面隔離原則(Interface Segregation Principle)

2.4.1 基本介紹

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

2.4.2 應用例項

 類圖：

介面隔離原則類圖實現 

package com.atguigu.principle.segregation;

public class Segregation1 {


public static void main(String[] args) {

}



}


//介面

interface Interface1 {


void operation1();
void operation2();
void operation3();
void operation4();
void operation5();



}


class B implements Interface1 {


@Override
public void operation1() {
    System.out.println("B 實現了 operation1");
}
@Override
public void operation2() {
    System.out.println("B 實現了 operation2");
}
@Override
public void operation3() {
    System.out.println("B 實現了 operation3");
}
@Override
public void operation4() {
    System.out.println("B 實現了 operation4");
}
@Override
public void operation5() {
    System.out.println("B 實現了 operation5");
}



}


class D implements Interface1 {


@Override
public void operation1() {
    System.out.println("D 實現了 operation1");
}
@Override
public void operation2() {
    System.out.println("D 實現了 operation2");
}
@Override
public void operation3() {
    System.out.println("D 實現了 operation3");
}
@Override
public void operation4() {
    System.out.println("D 實現了 operation4");
}
@Override
public void operation5() {
    System.out.println("D 實現了 operation5");
}



}


class A { //A 類通過介面Interface1 依賴(使用) B類，但是隻會用到1,2,3方法


public void depend1(Interface1 i) {
    i.operation1();
}
public void depend2(Interface1 i) {
    i.operation2();
}
public void depend3(Interface1 i) {
    i.operation3();
}



}


class C { //C 類通過介面Interface1 依賴(使用) D類，但是隻會用到1,4,5方法


public void depend1(Interface1 i) {
    i.operation1();
}
public void depend4(Interface1 i) {
    i.operation4();
}
public void depend5(Interface1 i) {
    i.operation5();
}



}

 問題：類 A 通過介面 Interface1 依賴類 B，類 C 通過介面 Interface1 依賴類 D，如果介面 Interface1 對於類 A 和類 C 來說不是最小介面，那麼類 B 和類 D 必須去實現他們不需要的方法。

2.4.3 使用介面隔離原則改進

上述問題解決辦法：將介面 Interface1 拆分為獨立的幾個介面，類 A 和類 C 分別與他們需要的介面建立依賴關係。即採用介面隔離原則。

使用介面隔離原則改進程式碼 

package com.atguigu.principle.segregation.improve;

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 {


@Override
public void operation1() {
    System.out.println("B 實現了 operation1");
}
@Override
public void operation2() {
    System.out.println("B 實現了 operation2");
}
@Override
public void operation3() {
    System.out.println("B 實現了 operation3");
}



}


class D implements Interface1, Interface3 {


@Override
public void operation1() {
    System.out.println("D 實現了 operation1");
}
@Override
public void operation4() {
    System.out.println("D 實現了 operation4");
}
@Override
public void operation5() {
    System.out.println("D 實現了 operation5");
}



}


class A { // A 類通過介面Interface1,Interface2 依賴(使用) B類，但是隻會用到1,2,3方法


public void depend1(Interface1 i) {
    i.operation1();
}

public void depend2(Interface2 i) {
    i.operation2();
}

public void depend3(Interface2 i) {
    i.operation3();
}



}


class C { // C 類通過介面Interface1,Interface3 依賴(使用) D類，但是隻會用到1,4,5方法


public void depend1(Interface1 i) {
    i.operation1();
}

public void depend4(Interface3 i) {
    i.operation4();
}

public void depend5(Interface3 i) {
    i.operation5();
}



}

2.5 依賴倒轉原則

2.5.1 基本介紹

依賴倒轉原則(Dependence Inversion Principle)是指：

  1. 高層模組不應該依賴低層模組，二者都應該依賴其抽象。

  2. 抽象不應該依賴細節，細節應該依賴抽象。

  3. 依賴倒轉(倒置)的中心思想是面向介面程式設計。

  4. 依賴倒轉原則是基於這樣的設計理念：相對於細節的多變性，抽象的東西要穩定的多。以抽象為基礎搭建的架構比以細節為基礎的架構要穩定的多。在java中，抽象指的是介面或抽象類，細節就是具體的實現類。

  5. 使用介面或抽象類的目的是制定好規範，而不涉及任何具體的操作，把展現細節的任務交給他們的實現類去完成。

2.5.2 應用例項

請程式設計完成 Person 接收訊息的功能

實現方案 1 + 分析說明

實現方案 1 

package com.atguigu.principle.inversion;

public class DependecyInversion {


public static void main(String[] args) {
    Person person = new Person();
    person.receive(new Email());
}



}


class Email {


public String getInfo() {
    return "電子郵件資訊: hello,world";
}



}


class Person {


public void receive(Email email ) {
    System.out.println(email.getInfo());
}



}

完成Person接收訊息的功能方式 1 分析

  1. 簡單，比較容易想到

  2. 如果我們獲取的物件是【微信，簡訊等等】，則新增類，同時Perons也要增加相應的接收方法。

  3. 解決思路：引入一個抽象的介面 IReceiver, 表示接收者, 這樣 Person 類與介面 IReceiver 發生依賴。因為 Email、WeiXin 等屬於接收的範圍，他們各自實現 IReceiver 介面就 ok，這樣我們就符合依賴倒轉原則。


實現方案 2 + 分析說明

實現方案 2 

package com.atguigu.principle.inversion.improve;

public class DependecyInversion {


public static void main(String[] args) {
    //客戶端無需改變
    Person person = new Person();
    person.receive(new Email());

    person.receive(new WeiXin());
}



}


//定義介面

interface IReceiver {


public String getInfo();



}


class Email implements IReceiver {


@Override
public String getInfo() {
    return "電子郵件資訊: hello,world";
}



}


//增加微信

class WeiXin implements IReceiver {


@Override
public String getInfo() {
    return "微信資訊: hello,ok";
}



}


//方式2

class Person {


//這裡是對介面的依賴
public void receive(IReceiver receiver ) {
    System.out.println(receiver.getInfo());
}



}

2.5.3 依賴關係傳遞的三種方式和應用案例

1、介面傳遞

應用案例程式碼

介面傳遞應用案例程式碼 

package com.atguigu.principle.inversion.improve;

public class DependencyPass {


public static void main(String[] args) {
    ChangHong changHong = new ChangHong();
    OpenAndClose openAndClose = new OpenAndClose();
    openAndClose.open(changHong);
}



}


// 方式1： 通過介面傳遞實現依賴

// 開關的介面

interface IOpenAndClose {


public void open(ITV tv); //抽象方法,接收介面



}


interface ITV { //ITV介面


public void play();



}


class ChangHong implements ITV {


@Override
public void play() {
	// TODO Auto-generated method stub
	System.out.println("長虹電視機，開啟");
}



}


// 實現介面

class OpenAndClose implements IOpenAndClose{


@Override
public void open(ITV tv){
    tv.play();
}



}

2、構造方法傳遞

應用案例程式碼

構造方法傳遞應用案例程式碼 

package com.atguigu.principle.inversion.improve;

public class DependencyPass {


public static void main(String[] args) {
    ChangHong changHong = new ChangHong();
    //通過構造器進行依賴傳遞
OpenAndClose openAndClose = new OpenAndClose(changHong);
openAndClose.open();
}



}


// 方式2: 通過構造方法依賴傳遞

interface IOpenAndClose {


 public void open(); //抽象方法



}


interface ITV { //ITV介面


 public void play();



}


class OpenAndClose implements IOpenAndClose{


 public ITV tv; //成員

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

 @Override
 public void open(){
     this.tv.play();
 }



}


class ChangHong implements ITV {


@Override
public void play() {
    System.out.println("長虹電視機，開啟");
}



}

3、setter 方式傳遞

應用案例程式碼

setter 方式傳遞應用案例程式碼 

package com.atguigu.principle.inversion.improve;

public class DependencyPass {


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

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



}


interface IOpenAndClose {


public void open(); // 抽象方法
public void setTv(ITV tv);



}


interface ITV { // ITV介面


public void play();



}


class OpenAndClose implements IOpenAndClose {


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



}


class ChangHong implements ITV {


@Override
public void play() {
    System.out.println("長虹電視機，開啟");
}



}

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

  1. 低層模組儘量都要有抽象類或介面，或者兩者都有，程式穩定性更好。

  2. 變數的宣告型別儘量是抽象類或介面，這樣變數引用和實際物件間，就存在一個緩衝層，利於程式擴充套件和優化。

  3. 繼承時遵循里氏替換原則。

2.6 里氏替換原則

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

1、繼承包含這樣一層含義：父類中凡是已經實現好的方法，實際上是在設定規範和契約，雖然它不強制要求所有的子類必須遵循這些契約，但是如果子類對這些已經實現的方法任意修改，就會對整個繼承體系造成破壞。

2、繼承在給程式設計帶來便利的同時，也帶來了弊端。比如使用繼承會給程式帶來侵入性，程式的可移植性降低，增加物件間的耦合性，如果一個類被其他的類所繼承，則當這個類需要修改時，必須考慮到所有的子類，並且父類修改後，所有涉及到子類的功能都有可能產生故障。

3、問題提出：在程式設計中，如何正確的使用繼承? => 里氏替換原則

2.6.2 基本介紹

1、里氏替換原則(Liskov SubstitutionPrinciple)在 1988 年，由麻省理工學院的 Liskov 女士提出的。

2、如果對每個型別為 T1 的物件 o1，都有型別為 T2 的物件 o2，使得以 T1 定義的所有程式 P 在所有的物件 o1 都代換成 o2 時，程式 P 的行為沒有發生變化，那麼型別 T2 是型別 T1 的子型別。換句話說，所有引用基類的地方必須能透明地使用其子類的物件。

3、在使用繼承時，遵循里氏替換原則，在子類中儘量不要重寫父類的方法。

4、里氏替換原則告訴我們，繼承實際上讓兩個類耦合性增強了，在適當的情況下，可以通過聚合，組合，依賴 來解決問題。

2.6.3 一個程式引出的問題和思考

2.6.4 解決方法

1、原來執行正常的相減功能發生了錯誤。原因就是類 B 無意中重寫了父類的方法，造成原有功能出現錯誤。在實際程式設計中，常常會通過重寫父類的方法完成新的功能，這樣寫起來雖然簡單，但整個繼承體系的複用性會比較差。特別是執行多型比較頻繁的時候。

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

解決方法 

package com.atguigu.principle.liskov.improve;

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("1-8=" + a.func1(1, 8));

	System.out.println("-----------------------");
	B b = new B();
	//因為B類不再繼承A類，因此呼叫者，不會再認為func1是求減法
	//呼叫完成的功能就會很明確
	System.out.println("11+3=" + b.func1(11, 3));//這裡本意是求出11+3
	System.out.println("1+8=" + b.func1(1, 8));// 1+8
	System.out.println("11+3+9=" + b.func2(11, 3));
			
	//使用組合仍然可以使用到A類相關方法
	System.out.println("11-3=" + b.func3(11, 3));// 這裡本意是求出11-3		
}



}


//建立一個更加基礎的基類

class Base {


//把更加基礎的方法和成員寫到Base類



}


// A類

class A extends Base {


// 返回兩個數的差
public int func1(int num1, int num2) {
	return num1 - num2;
}



}


// B類繼承了A

// 增加了一個新功能：完成兩個數相加,然後和9求和

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);
}



}

2.7 開閉原則

2.7.1 基本介紹

1、開閉原則（Open Closed Principle）是程式設計中最基礎、最重要的設計原則。

2、一個軟體實體如類，模組和函式應該對擴充套件開放(對提供方)，對修改關閉(對使用方)。用抽象構建框架，用實現擴充套件細節。

3、當軟體需要變化時，儘量通過擴充套件軟體實體的行為來實現變化，而不是通過修改已有的程式碼來實現變化。即增加新功能，儘量不修改程式碼，而是增加程式碼。

4、程式設計中遵循其它原則，以及使用設計模式的目的就是遵循開閉原則。

2.7.2 看下面一段程式碼

看一個畫圖形的功能。

類圖設計，如下:

畫圖形的功能程式碼實現 

package com.atguigu.principle.ocp;

public class Ocp {


public static void main(String[] args) {
	//使用看看存在的問題
	GraphicEditor graphicEditor = new GraphicEditor();
	graphicEditor.drawShape(new Rectangle());
	graphicEditor.drawShape(new Circle());
}



}


//這是一個用於繪圖的類 [使用方]

class GraphicEditor {


//接收Shape物件，然後根據type，來繪製不同的圖形
public void drawShape(Shape s) {
	if (s.m_type == 1)
		drawRectangle(s);
	else if (s.m_type == 2)
		drawCircle(s);
}

//繪製矩形
public void drawRectangle(Shape r) {
	System.out.println(" 繪製矩形 ");
}

//繪製圓形
public void drawCircle(Shape r) {
	System.out.println(" 繪製圓形 ");
}



}


//Shape類，基類

class Shape {


int m_type;



}


class Rectangle extends Shape {


Rectangle() {
	super.m_type = 1;
}



}


class Circle extends Shape {


Circle() {
	super.m_type = 2;
}



}

2.7.3 上述實現的優缺點

1、優點是簡單易操作。

2、缺點是違反了設計模式的ocp原則，即對擴充套件開放(提供方)，對修改關閉(使用方)。即當給類增加新功能的時候，儘量不修改程式碼，或者儘可能少修改程式碼。

3、比如要新增加一個圖形種類 三角形，需要做如下修改，修改的地方較多。

程式碼演示

新增三角形 

public class Ocp {

public static void main(String[] args) {
    //使用看看存在的問題
    GraphicEditor graphicEditor = new GraphicEditor();
    graphicEditor.drawShape(new Rectangle());
    graphicEditor.drawShape(new Circle());
    graphicEditor.drawShape(new Triangle());
}



}


//這是一個用於繪圖的類 [

相關推薦

第 2 章 設計模式七大原則

目錄2.1 設計模式的目的2.2 設計模式七大原則2.3 單一職責原則2.3.1 基本介紹2.3.2 應用例項2.3.3 單一職責原則注意事項和細節2.4 介面隔離原則(Interface Segregation Principle)2.4.1 基本介紹2.4.2 應用例項2.4.3

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

目錄前言1. 單一職責原則 Single Responsibility Principle1.1 基本介紹1.2 單一職責原則注意事項和細節1.3 一個示例2. 介面隔離原則 Interface Segregation Principle2.1 基本介紹2.2 圖解2.3 一個示例3. 依賴倒轉

設計模式七大原則之裡式替換原則

1、裡式替換原則在1988年，由麻省理工學院的一位姓裡的女士提出的。 2、所有引用基類的地方必須能透明地使用子類的物件

設計模式七大原則

設計模式七大原則 單一職責原則 對類來說，一個類只負責一項職責。比如說A類有兩個職責，職責1，職責2；那麼就可以把A類分為兩個類，這就是遵循了單一職責原則

設計模式七大原則及程式碼示例

七大原則： 單一職責原則； 介面隔離原則； 依賴倒轉原則； 里氏替換原則； 開閉原則ocp；

設計模式七大原則-迪米特法則

基本介紹： 一個物件應該對其他物件保持最少的瞭解 類與類關係越密切，耦合度越大

設計模式——七大原則

設計模式的目的是為了讓程式，具有更好的程式碼重用性、可讀性（程式設計規範性，便於後期維護和理解）、可擴充套件性（當需要增加新需求時，非常方便）、可靠性（增加新功能後，對原功能麼有影響）、使程式呈現高

設計模式七大原則03---依賴倒轉原則

一、依賴倒轉原則(Dependence Inversion Principle)特點 1、依賴倒轉原則是基於這樣的設計理念:相對於細節的多變性,抽象的東西要穩定的多.以抽象為基礎搭建的架構比以細節為基礎的架構要穩定的多.在java中,抽象指的是

JAVA設計模式--七大原則之單一職責（01）

技術標籤：設計模式 一個類，只有一個引起它變化的原因。應該只有一個職責。每一個職責都是變化的一個軸線，如果一個類有一個以上的職責，這些職責就耦合在了一起。這會導致脆弱的設計。當一個職責發生變化時，可

JAVA設計模式--七大原則之里氏替換原則（04）

技術標籤：設計模式 里氏代換原則(Liskov Substitution Principle LSP)面向物件設計的基本原則之一。

JAVA設計模式--七大原則之開閉原則（05）

技術標籤：設計模式 開閉原則就是說對擴充套件開放，對修改關閉。 擴充套件開放---對提供方（新增加的功能）

設計模式七大原則之單一職責

技術標籤：設計模式 設計模式:其實就是程式設計師在程式設計時，應當遵守的原則，也是各種設計模式的基礎 目的：編寫軟體過程中，程式設計師會面臨著來自耦合性，內聚性以及可維護性，可擴充套件性，可重用性，靈

java設計模式七大原則

導圖設計：     1.開閉原則 （Open Close Principle）- 對擴充套件開放，對更改關閉-保證以前程式碼的準確性，使開發者更專注於新擴充套件的程式碼上

設計模式七大原則—依賴倒置原則

1.基本介紹 1.1.概念 高層模組不能依賴於一個“具體化、細節化”的低層模組，而是通過一個抽象的“規範/標準”建立兩者之間的依賴關係，簡言之就是：不依賴於實現，而是依賴於抽象。這裡“實現”一詞有的地方也稱為

設計模式七大原則—里氏替換原則

1.基本介紹 里斯科瓦（Barbara Liskov）使美國麻省理工學院電氣工程於計算機科學系資深教授，她是美國國家工程院院士，在程式語言、分散式計算、程式設計方法及軟體工程領域做出了卓越貢獻。里斯科瓦於1987年提出了

設計模式七大原則—開閉原則

重要性 有過一些實際開發工作的朋友一定對某個場景會深有體會，那就是客戶經常會對現有的功能提出新的需求要我們改動，並且要快速完成。如果你的程式碼沒有很好的遵循“開閉原則”，並且頂著工期的縮減，那我們對需

設計模式七大原則—迪米特法則

1.概念 1.1.知道的越少越好 迪米特法則，結合其含義又稱之為“最少知道原則”，即一個類作為一個呼叫方，應當對自己依賴的類(被呼叫的類)其中所處理的邏輯細節，知道的越少越好。對於被依賴的類(被呼叫的類)不管在使

大話設計模式讀書筆記(第2章)

人物：小菜，大鳥 事件：做一個商場收銀軟體，營業員根據客戶所購買的商品的單價和數量，向客戶收費

【大話設計模式】第2章　商場促銷——策略模式（Java）

技術標籤：Java設計模式java 聚合：表示一種弱的擁有關係，體現的是A物件可以包含B物件，但B物件不是A物件的一部分實現：繼承了箭頭指向的類

《微服務架構設計模式》讀書筆記 | 第2章 服務的拆分策略

目錄前言1. 微服務架構到底是什麼1.1 軟體架構的4+1檢視1.2 應用程式的兩個層面需求1.3 分層式架構風格1.4 關於架構風格的六邊形1.5 什麼是服務1.6 微服務架構的架構風格2 為應用程式定義微服務架構2.1 定義應用程式