聊聊OOP中的設計原則以及訪問者模式

袋鼠雲數棧UED發表於2022-06-02

OOP模式

一設計原則 (SOLID)

1. S - 單一職責原則（Single Responsibllity Principle）

1.1 定義

一個類或者模組只負責完成一個職責（或功能), 認為“物件應該僅具有一種單一功能”的概念, 如果一個類包含了兩個或兩個以上業務沒有關聯的功能，就被認為是職責不夠單一，可以差分成多個功能單一的類

1.2 舉個例子

Employee 類裡面包含了多個不同的行為, 違背了單一指責原則

file

通過拆分出 TimeSheetReport 類, 依賴了 Employee 類, 遵循單一指責原則
file

2. O - 開放關閉原則（Open-Closed Principle）

2.1 定義

軟體實體（包括類、模組、功能等）應該對擴充套件開放，但是對修改關閉, 滿足以下兩個特性

對擴充套件開放

模組對擴充套件開放，就意味著需求變化時，可以對模組擴充套件，使其具有滿足那些改變的新行為

對修改關閉

模組對修改關閉，表示當需求變化時，應該儘量在不修改原始碼的基礎上面擴充套件功能

2.2 舉個例子

在訂單中需要根據不同的運輸方式計算運輸成本

Order

類中計算運輸成本，如果後續再增加新的運輸方式，就需要修改Order原來的方法getShippingCost() , 違背了OCP
file

根據多型的思想，可以將 shipping 抽象成一個類, 後續新增運輸方式, 無須修改Order 類原有的方法,
只需要在增加一個Shipping的派生類就可以了
file

3. L - 里氏替換原則（Liskov Substitution Principle）

3.1 定義

使用父類的地方都可以用子類替代，子類能夠相容父類

子類方法的引數型別應該比父類方法的引數型別更抽象或者說範圍更廣
子類方法的返回值型別應該比父類方法的返回值型別更具體或者說範圍更小

3.2 舉個例子

子類方法的引數型別應該比父類方法的引數型別更抽象或者說範圍更廣
演示 demo

class Animal {}
class Cat extends Animal {
  faviroteFood: string;
  constructor(faviroteFood: string) {
    super();
    this.faviroteFood = faviroteFood;
  }
}

class Breeder {
  feed(c: Animal) {
    console.log("Breeder feed animal");
  }
}

class CatCafe extends Breeder {
  feed(c: Animal) {
    console.log("CatCafe feed animal");
  }
}

const animal = new Animal();

const breeder = new Breeder();
breeder.feed(animal);
// 約束子類能夠接受父類入參
const catCafe = new CatCafe();
catCafe.feed(animal);

子類方法的返回值型別應該比父類方法的返回值型別更具體或者說範圍更小

class Animal {}

class Cat extends Animal {
  faviroteFood: string;
  constructor(faviroteFood: string) {
    super();
    this.faviroteFood = faviroteFood;
  }
}

class Breeder {
  buy(): Animal {
    return new Animal();
  }
}

class CatCafe extends Breeder {
  buy(): Cat {
    return new Cat("");
  }
}

const breeder = new Breeder();
let a: Animal = breeder.buy();

const catCafe = new CatCafe();
a = catCafe.buy();

子類不應該強化前置條件
子類不應該弱化後置條件

4. I - 介面隔離原則（Interface Segregation Principle）

4.1 定義

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

4.2 舉個例子

類 A 通過介面 I 依賴類 B，類 C 通過介面 I 依賴類 D，如果介面 I 對於類 A 和類 B 來說不是最小介面，則類 B 和類 D 必須去實現他們不需要的方法

interface I {
  m1(): void;
  m2(): void;
  m3(): void;
  m4(): void;
  m5(): void;
}

class B implements I {
  m1(): void {}
  m2(): void {}
  m3(): void {}
  //實現的多餘方法
  m4(): void {}
  //實現的多餘方法
  m5(): void {}
}

class A {
  m1(i: I): void {
    i.m1();
  }
  m2(i: I): void {
    i.m2();
  }
  m3(i: I): void {
    i.m3();
  }
}

class D implements I {
  m1(): void {}
  //實現的多餘方法
  m2(): void {}
  //實現的多餘方法
  m3(): void {}
  
  m4(): void {}
  m5(): void {}
}

class C {
  m1(i: I): void {
    i.m1();
  }
  m4(i: I): void {
    i.m4();
  }
  m5(i: I): void {
    i.m5();
  }
}

將臃腫的介面 I 拆分為獨立的幾個介面，類 A 和類 C 分別與他們需要的介面建立依賴關係

interface I {
  m1(): void;
}

interface I2 {
  m2(): void;
  m3(): void;
}

interface I3 {
  m4(): void;
  m5(): void;
}

class B implements I, I2 {
  m1(): void {}
  m2(): void {}
  m3(): void {}
}

class A {
  m1(i: I): void {
    i.m1();
  }
  m2(i: I2): void {
    i.m2();
  }
  m3(i: I2): void {
    i.m3();
  }
}

class D implements I, I3 {
  m1(): void {}
  m4(): void {}
  m5(): void {}
}

class C {
  m1(i: I): void {
    i.m1();
  }
  m4(i: I3): void {
    i.m4();
  }
  m5(i: I3): void {
    i.m5();
  }
}

4.3 現實中的栗子

以電動自行車為例

file

普通的電動自行車並沒有定位和檢視歷史行程的功能，但由於實現了介面 ElectricBicycle ，所以必須實現介面中自己不需要的方法。更好的方式是進行拆分

file

5. D - 依賴倒置原則

5.1 定義

依賴一個抽象的服務介面，而不是去依賴一個具體的服務執行者，從依賴具體實現轉向到依賴抽象介面，倒置過來
在軟體設計中可以將類分為兩個級別：高層模組, 低層模組, 高層模組不應該依賴低層模組，兩者都應該依賴其抽象。高層模組指的是呼叫者，低層模組指的是一些基礎操作

依賴倒置基於這個事實：相比於實現細節的多變性，抽象的內容要穩定的多

5.2 舉個例子

SoftwareProject類直接依賴了兩個低階類, FrontendDeveloper 和 BackendDeveloper, 而此時來了一個新的低層模組,就要修改高層模組 SoftwareProject 的依賴

class FrontendDeveloper {
  public writeHtmlCode(): void {
    // some method
  }
}

class BackendDeveloper {
  public writeTypeScriptCode(): void {
    // some method
  }
}

class SoftwareProject {
  public frontendDeveloper: FrontendDeveloper;
  public backendDeveloper: BackendDeveloper;

  constructor() {
    this.frontendDeveloper = new FrontendDeveloper();
    this.backendDeveloper = new BackendDeveloper();
  }

  public createProject(): void {
    this.frontendDeveloper.writeHtmlCode();
    this.backendDeveloper.writeTypeScriptCode();
  }
}

可以遵循依賴倒置原則, 由於 FrontendDeveloper 和 BackendDeveloper是相似的類, 可以抽象出一個 develop 介面, 讓FrontendDeveloper 和BackendDeveloper 去實現它, 我們不需要在 SoftwareProject類中以單一方式初始化 FrontendDeveloper 和 BackendDeveloper，而是將它們作為一個列表來遍歷它們，分別呼叫每個 develop() 方法

interface Developer {
  develop(): void;
}

class FrontendDeveloper implements Developer {
  public develop(): void {
    this.writeHtmlCode();
  }
  
  private writeHtmlCode(): void {
    // some method
  }
}

class BackendDeveloper implements Developer {
  public develop(): void {
    this.writeTypeScriptCode();
  }
  
  private writeTypeScriptCode(): void {
    // some method
  }
}

class SoftwareProject {
  public developers: Developer[];
  
  public createProject(): void {
    this.developers.forEach((developer: Developer) => {
      developer.develop();
    });
  }
}

二訪問者模式 (Visitor Pattern)

1. 意圖

表示一個作用於某物件結構中的各元素的操作。它使你可以在不改變各元素的類的前提下定義作用於這些元素的新操作

Visitor的作用，即 作用於某物件結構中的各元素的操作，也就是 Visitor 是用於操作物件元素的
它使你可以在不改變各元素的類的前提下定義作用於這些元素的新操作 也就是說，你可以只修Visitor 本身完成新操作的定義，而不需要修改原本物件, Visitor設計奇妙之處, 就是將物件的操作權移交給了 Visitor

2. 場景

如果你需要對一個複雜物件結構（例如物件樹）中的所有元素執行某些操作，可使用訪問者模式
訪問者模式通過在訪問者物件中為多個目標類提供相同操作的變體，讓你能在屬於不同類的一組物件上執行同一操作

3. 訪問者模式結構

Visitor：訪問者介面
ConcreteVisitor：具體的訪問者
Element: 可以被訪問者使用的元素，它必須定義一個 Accept 屬性，接收 visitor 物件。這是實現訪問者模式的關鍵

file

可以看到，要實現操作權轉讓到 Visitor，核心是元素必須實現一個 Accept 函式，將這個物件拋給 Visitor：

class ConcreteElement implements Element {
  public accept(visitor: Visitor) {
    visitor.visit(this)
  }
}

從上面程式碼可以看出這樣一條鏈路：Element 通過 accept函式接收到 Visitor 物件，並將自己的例項拋給 Visitor 的 visit函式，這樣我們就可以在 Visitor 的 visit 方法中拿到物件例項，完成對物件的操作

4 . 實現方式以及虛擬碼

在本例中， 訪問者模式為幾何影像層次結構新增了對於 XML 檔案匯出功能的支援

4.1 在訪問者介面中宣告一組 “訪問” 方法，分別對應程式中的每個具體元素類

interface Visitor {
  visitDot(d: Dot): void;
  visitCircle(c: Circle): void;
  visitRectangle(r: Rectangle): void;
}

4.2 宣告元素介面。如果程式中已有元素類層次介面，可在層次結構基類中新增抽象的 “接收” 方法。該方法必須接受訪問者物件作為引數

interface Shape {
  accept(v: Visitor): void;
}

4.3 在所有具體元素類中實現接收方法, 元素類只能通過訪問者介面與訪問者進行互動,不過訪問者必須知曉所有的具體元素類，因為這些類在訪問者方法中都被作為引數型別引用

class Dot implements Shape {
  public accept(v: Visitor): void {
   return v.visitDot(this)
  }
}

class Circle implements Shape {
  public accept(v: Visitor): void {
   return v.visitCircle(this)
  }
}

class Rectangle implements Shape {
  public accept(v: Visitor): void {
    return v.visitRectangle(this)
  }
}

4.4 建立一個具體訪問者類並實現所有的訪問者方法

class XMLExportVisitor implements Visitor {
    visitDot(d: Dot): void {
      console.log(`匯出點（dot）的 ID 和中心座標`);
    }
    visitCircle(c: Circle): void {
      console.log(`匯出圓（circle）的 ID 、中心座標和半徑`);
    }
    visitRectangle(r: Rectangle): void {
      console.log(`匯出長方形（rectangle）的 ID 、左上角座標、寬和長`);
    }
}

4.5 客戶端必須建立訪問者物件並通過 “接收” 方法將其傳遞給元素

const application = (shapes:Shape[],visitor:Visitor) => {
  // ......
   for (const shape of  allShapes) {
      shape.accept(visitor);
    }
  // ......
}
	
const allShapes = [
    new Dot(),
    new Circle(),
    new Rectangle()
];

const xmlExportVisitor = new XMLExportVisitor();
application(allShapes, xmlExportVisitor);

4.6 完整程式碼預覽

interface Visitor {
    visitDot(d: Dot): void;
    visitCircle(c: Circle): void;
    visitRectangle(r: Rectangle): void;
}

interface Shape {
   accept(v: Visitor): void;
}

class Dot implements Shape {
  public accept(v: Visitor): void {
     return v.visitDot(this)
  }
}

class Circle implements Shape {
  public accept(v: Visitor): void {
    return v.visitCircle(this)
  }
}

class Rectangle implements Shape {
  public accept(v: Visitor): void {
    return v.visitRectangle(this)
  }
}

class XMLExportVisitor implements Visitor {
    visitDot(d: Dot): void {
      console.log(`匯出點（dot）的 ID 和中心座標`);
    }
    visitCircle(c: Circle): void {
      console.log(`匯出圓（circle）的 ID 、中心座標和半徑`);
    }
    visitRectangle(r: Rectangle): void {
      console.log(`匯出長方形（rectangle）的 ID 、左上角座標、寬和長`);
    }
}

const allShapes = [
    new Dot(),
    new Circle(),
    new Rectangle()
];

const application = (shapes:Shape[],visitor:Visitor) => {
  // ......
for (const shape of  allShapes) {
    shape.accept(visitor);
  // .....
}
	
const xmlExportVisitor = new XMLExportVisitor();
application(allShapes, xmlExportVisitor);

5. 訪問者模式優缺點

優勢:

開閉原則。你可以引入在不同類物件上執行的新行為，且無需對這些類做出修改
單一職責原則可將同一行為的不同版本移到同一個類中

不足:

每次在元素層次結構中新增或移除一個類時, 你都要更新所有的訪問者
在訪問者同某個元素進行互動時，它們可能沒有訪問元素私有成員變數和方法的必要許可權

設計模式 - ASM 中的訪問者模式
2018-10-28
設計模式ASM
設計模式：訪問者模式
2014-03-22
設計模式
設計模式中的那些原則
2014-11-02
設計模式
設計模式（十六）——訪問者模式
2021-02-06
設計模式
Java中的設計模式和原則
2020-10-12
Java設計模式
極簡設計模式-訪問者模式
2021-12-10
設計模式
JAVA設計模式之訪問者模式
2016-12-18
Java設計模式
設計模式解密（22）- 訪問者模式
2017-08-19
設計模式解密
PHP設計模式之訪問者模式
2016-02-29
PHP設計模式
物件導向設計原則，以及包的設計原則
2009-03-25
物件
oop原則
2020-09-23
OOP
設計模式的設計原則
2021-11-11
設計模式
設計模式學習之訪問者模式
2018-12-11
設計模式
【趣味設計模式系列】之【訪問者模式】
2020-09-07
設計模式
C#設計模式之訪問者模式
2018-06-08
C#設計模式
23種設計模式之訪問者模式
2015-04-05
設計模式
設計原則設計模式
2020-08-24
設計模式
設計模式 - 設計原則
2021-04-14
設計模式
【設計模式】設計原則
2022-06-29
設計模式
設計模式（二十三）訪問者
2024-01-29
設計模式
15.java設計模式之訪問者模式
2020-11-27
Java設計模式
18、Python與設計模式–訪問者模式
2017-02-27
Python設計模式
【設計模式——六原則】
2016-03-12
設計模式
設計模式的征途—16.訪問者（Visitor）模式
2017-07-30
設計模式
物件導向程式設計（OOP）的七大原則
2023-03-27
物件程式設計OOP
C#設計模式系列：訪問者模式（Visitor）
2014-04-09
C#設計模式
設計模式--訪問者模式Visitor（行為型）
2014-04-15
設計模式
JAVA設計模式之訪問者模式【Visitor Pattern】
2014-11-15
Java設計模式
Javascript 設計模式之設計原則
2019-07-21
JavaScript設計模式
JavaScript設計模式（一）設計原則
2018-11-08
JavaScript設計模式
設計模式（07）——設計原則（2）
2020-12-05
設計模式
設計模式（06）——設計原則（1）
2020-12-01
設計模式
設計模式學習-設計原則
2017-12-21
設計模式
從設計模式的設計原則感悟生活
2014-11-26
設計模式
設計模式 -- 設計模式七大原則
2020-11-01
設計模式
「補課」進行時：設計模式(18)——訪問者模式
2020-12-14
設計模式
設計模式學習-使用go實現訪問者模式
2021-11-26
設計模式Go
Java進階篇設計模式之十 ---- 訪問者模式和中介者模式
2018-11-05
Java設計模式

聊聊OOP中的設計原則以及訪問者模式

一 設計原則 (SOLID)

1. S - 單一職責原則（Single Responsibllity Principle）

2. O - 開放關閉原則（Open-Closed Principle）

3. L - 里氏替換原則（Liskov Substitution Principle）

4. I - 介面隔離原則（Interface Segregation Principle）

5. D - 依賴倒置原則

二 訪問者模式 (Visitor Pattern)

1. 意圖

2. 場景

3. 訪問者模式結構

4 . 實現方式以及虛擬碼

5. 訪問者模式優缺點

相關文章

一設計原則 (SOLID)

二訪問者模式 (Visitor Pattern)