一 設計原則 (SOLID)
1. S - 單一職責原則（Single Responsibllity Principle）
1.1 定義
一個類或者模塊只負責完成一個職責（或功能), 認為“物件應該僅具有一種單一功能”的概念, 如果一個類包含了兩個或兩個以上業務沒有關聯的功能，就被認為是職責不夠單一，可以差分成多個功能單一的類
1.2 舉個栗子
Employee 類里面包含了多個不同的行為, 違背了單一指責原則
通過拆分出 TimeSheetReport 類, 依賴了 Employee 類, 遵循單一指責原則
2. O - 開放關閉原則（Open-Closed Principle）
2.1 定義
軟體物體（包括類、模塊、功能等）應該對擴展開放，但是對修改關閉, 滿足以下兩個特性
- 對擴展開放
模塊對擴展開放，就意味著需求變化時，可以對模塊擴展，使其具有滿足那些改變的新行為
- 對修改關閉
模塊對修改關閉，表示當需求變化時，應該盡量在不修改源代碼的基礎上面擴展功能
2.2 舉個栗子
在訂單中需要根據不同的運輸方式計算運輸成本
Order
類中計算運輸成本，如果后續再增加新的運輸方式，就需要修改Order原來的方法getShippingCost() , 違背了OCP
根據多型的思想，可以將 shipping 抽象成一個類, 后續新增運輸方式, 無須修改Order 類原有的方法,
只需要在增加一個Shipping的派生類就可以了
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 現實中的栗子
以電動自行車為例
普通的電動自行車并沒有定位和查看歷史行程的功能，但由于實作了介面 ElectricBicycle ，所以必須實作介面中自己不需要的方法，更好的方式是進行拆分
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 物件，這是實作訪問者模式的關鍵
可以看到，要實作操作權轉讓到 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. 訪問者模式優缺點
優勢:
- 開閉原則， 你可以引入在不同類物件上執行的新行為， 且無需對這些類做出修改
- 單一職責原則 可將同一行為的不同版本移到同一個類中
不足:
- 每次在元素層次結構中添加或移除一個類時, 你都要更新所有的訪問者
- 在訪問者同某個元素進行互動時， 它們可能沒有訪問元素私有成員變數和方法的必要權限
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/498977.html
標籤：設計模式
上一篇：設計原則之DRY原則
下一篇：LSP原則是什么