設計模式是可以幫助開發人員解決問題的模板。在本中涉及的模式太多了,而且它們往往針對不同的需求。但是,它們可以被分為三個不同的組:
Composite
、Adapter
和Decorator
。觀察者模式
。單例模式可能是最著名的設計模式之一。它是一種建立模式,因為它確保無論我們嘗試範例化一個類多少次,我們都只有一個可用的範例。
處理資料庫連線之類的可以單例模式,因為我們希望一次只處理一個,而不必在每個使用者請求時重新連線。
class MyDBConn { protected static instance: MyDBConn | null = null private id:number = 0 constructor() { this.id = Math.random() } public getID():number { return this.id } public static getInstance():MyDBConn { if (!MyDBConn.instance) { MyDBConn.instance = new MyDBConn() } return MyDBConn.instance } } const connections = [ MyDBConn.getInstance(), MyDBConn.getInstance(), MyDBConn.getInstance(), MyDBConn.getInstance(), MyDBConn.getInstance() ] connections.forEach( c => { console.log(c.getID()) })
現在,雖然不能直接範例化類,但是使用getInstance
方法,可以確保不會有多個範例。在上面的範例中,可以看到包裝資料庫連線的偽類如何從該模式中獲益。
這個事例展示了無論我們呼叫getInstance
方法多少次,這個連線總是相同的。
上面的執行結果:
0.4047087250990713 0.4047087250990713 0.4047087250990713 0.4047087250990713 0.4047087250990713
工廠模式
是一種建立模式,就像單例模式
一樣。但是,這個模式並不直接在我們關心的物件上工作,而是隻負責管理它的建立。
解釋一下:假設我們通過編寫程式碼來模擬移動車輛,車有很多型別,例如汽車、自行車和飛機,移動程式碼應該封裝在每個vehicle
類中,但是呼叫它們的move
方法的程式碼可以是通用的。
這裡的問題是如何處理物件建立?可以有一個具有3個方法的單一creator
類,或者一個接收引數的方法。在任何一種情況下,擴充套件該邏輯以支援建立更多vehices
都需要不斷增長相同的類。
但是,如果決定使用工廠方法模式,則可以執行以下操作:
現在,建立新物件所需的程式碼被封裝到一個新類中,每個類對應一個車輛型別。這確保瞭如果將來需要新增車輛,只需要新增一個新類,而不需要修改任何已經存在的東西。
接著來看看,我們如何使用TypeScript
來實現這一點:
interface Vehicle { move(): void } class Car implements Vehicle { public move(): void { console.log("Moving the car!") } } class Bicycle implements Vehicle { public move(): void { console.log("Moving the bicycle!") } } class Plane implements Vehicle { public move(): void { console.log("Flying the plane!") } } // VehicleHandler 是「抽象的」,因為沒有人會範例化它instantiate it // 我們要擴充套件它並實現抽象方法 abstract class VehicleHandler { // 這是真正的處理程式需要實現的方法 public abstract createVehicle(): Vehicle public moveVehicle(): void { const myVehicle = this.createVehicle() myVehicle.move() } } class PlaneHandler extends VehicleHandler{ public createVehicle(): Vehicle { return new Plane() } } class CarHandler extends VehicleHandler{ public createVehicle(): Vehicle { return new Car() } } class BicycleHandler extends VehicleHandler{ public createVehicle(): Vehicle { return new Bicycle() } } /// User code... const planes = new PlaneHandler() const cars = new CarHandler() planes.moveVehicle() cars.moveVehicle()
上面的程式碼很多,但我們可以使用上面的圖表來理解它。本質上最後,我們關心的是自定義處理程式,這裡稱它為處理程式,而不是創造者,因為他們不只是建立的物件,他們也有邏輯,使用它們(moveVehicle方法)。
這個模式的美妙之處在於,如果您你要新增一個新的vehicle
型別,所要做的就是新增它的vehicle
類和它的處理程式類,而不增加任何其他類的LOC。
在所有的模式,我最喜歡的是觀察者模式
,因為型別的行為我們可以實現它。
它是如何工作的呢?本質上,該模式表明你擁有一組觀察者物件,這些物件將對被觀察實體狀態的變化做出反應。為了實現這一點,一旦在被觀察端接收到一個更改,它就負責通過呼叫它的一個方法來通知它的觀察者。
在實踐中,此模式的實現相對簡單,讓我們快速檢視一下程式碼,然後回顧一下
type InternalState = { event: String } abstract class Observer { abstract update(state:InternalState): void } abstract class Observable { protected observers: Observer[] = [] protected state:InternalState = { event: ""} public addObserver(o: Observer):void { this.observers.push(o) } protected notify () { this.observers.forEach(o => o.update(this.state)) } } class ConsoleLogger extends Observer { public update(newState: InternalState) { console.log("New internal state update: ", newState) } } class InputElement extends Observable { public click():void { this.state = { event: "click" } this.notify() } } const input = new InputElement() input.addObserver(new ConsoleLogger()) input.click()
正如你所看到的,通過兩個抽象類,我們可以定義Observer
,該觀察者將表示對Observable
實體上的更改做出反應的物件。 在上面的範例中,我們假設具有一個被單擊的InputElement
實體(類似於在前端具有HTML輸入欄位的方式),以及一個ConsoleLogger
,用於記錄控制檯發生的所有事情。
這種模式的優點在於,它使我們能夠了解Observable
的內部狀態並對其做出反應,而不必弄亂其內部程式碼。 我們可以繼續新增執行其他操作的觀察者,甚至包括對特定事件做出反應的觀察者,然後讓它們的程式碼決定對每個通知執行的操作。
裝飾模式試圖在執行時向現有物件新增行為。 從某種意義上說,我們可以將其視為動態繼承,因為即使沒有建立新類來新增行為,我們也正在建立具有擴充套件功能的新物件。
這樣考慮:假設我們擁有一個帶有move
方法的Dog
類,現在您想擴充套件其行為,因為我們想要一隻超級狗和一隻可以游泳的狗。
通常,我們需要在 Dog 類中新增move
行為,然後以兩種方式擴充套件該類,即SuperDog
和SwimmingDog
類。 但是,如果我們想將兩者混合在一起,則必須再次建立一個新類來擴充套件它們的行為,但是,有更好的方法。
組合讓我們可以將自定義行為封裝在不同的類中,然後使用該模式通過將原始物件傳遞給它們的建構函式來建立這些類的新範例。 讓我們看一下程式碼:
abstract class Animal { abstract move(): void } abstract class SuperDecorator extends Animal { protected comp: Animal constructor(decoratedAnimal: Animal) { super() this.comp = decoratedAnimal } abstract move(): void } class Dog extends Animal { public move():void { console.log("Moving the dog...") } } class SuperAnimal extends SuperDecorator { public move():void { console.log("Starts flying...") this.comp.move() console.log("Landing...") } } class SwimmingAnimal extends SuperDecorator { public move():void { console.log("Jumps into the water...") this.comp.move() } } const dog = new Dog() console.log("--- Non-decorated attempt: ") dog.move() console.log("--- Flying decorator --- ") const superDog = new SuperAnimal(dog) superDog.move() console.log("--- Now let's go swimming --- ") const swimmingDog = new SwimmingAnimal(dog) swimmingDog.move()
注意幾個細節:
SuperDecorator
類擴充套件了Animal
類,與Dog
類擴充套件了相同的類。 這是因為裝飾器需要提供與其嘗試裝飾的類相同的公共介面。SuperDecorator
類是abstract
,這意味著並沒有使用它,只是使用它來定義建構函式,該建構函式會將原始物件的副本保留在受保護的屬性中。 公共介面的覆蓋是在自定義裝飾器內部完成的。SuperAnimal
和SwimmingAnimal
是實際的裝飾器,它們是新增額外行為的裝飾器。進行此設定的好處是,由於所有裝飾器也間接擴充套件了Animal
類,因此如果你要將兩種行為混合在一起,則可以執行以下操作:
const superSwimmingDog = new SwimmingAnimal(superDog) superSwimmingDog.move()
關於Composite模式,其實就是組合模式,又叫部分整體模式,這個模式在我們的生活中也經常使用。
比如編寫過前端的頁面,肯定使用過<p>
等標籤定義一些格式,然後格式之間互相組合,通過一種遞迴的方式組織成相應的結構,這種方式其實就是組合,將部分的元件鑲嵌到整體之中。
關於此模式的有趣之處在於,它不是一個簡單的物件組,它可以包含實體或實體組,每個組可以同時包含更多組,這就是我們所說的樹。
看一個例子:
interface IProduct { getName(): string getPrice(): number } class Product implements IProduct { private price:number private name:string constructor(name:string, price:number) { this.name = name this.price = price } public getPrice():number { return this.price } public getName(): string { return this.name } } class Box implements IProduct { private products: IProduct[] = [] contructor() { this.products = [] } public getName(): string { return "A box with " + this.products.length + " products" } add(p: IProduct):void { console.log("Adding a ", p.getName(), "to the box") this.products.push(p) } getPrice(): number { return this.products.reduce( (curr: number, b: IProduct) => (curr + b.getPrice()), 0) } } //Using the code... const box1 = new Box() box1.add(new Product("Bubble gum", 0.5)) box1.add(new Product("Samsung Note 20", 1005)) const box2 = new Box() box2.add( new Product("Samsung TV 20in", 300)) box2.add( new Product("Samsung TV 50in", 800)) box1.add(box2) console.log("Total price: ", box1.getPrice())
在上面的範例中,我們可以將product
放入Box
中,也可以將Box
放入其他Box
中,這是組合的經典範例。因為我們要實現的是獲得完整的交付價格,因此需要在大box
裡新增每個元素的價格(包括每個小box
的價格)。
上面執行的結果:
Adding a Bubble gum to the box Adding a Samsung Note 20 to the box Adding a Samsung TV 20in to the box Adding a Samsung TV 50in to the box Adding a A box with 2 products to the box Total price: 2105.5
因此,在處理遵循同一介面的多個物件時,請考慮使用此模式。 通過將複雜性隱藏在單個實體(組合本身)中,您會發現它有助於簡化與小組的互動方式。
今天的分享就到這裡了,感謝大家的觀看,我們下期再見。
原文地址:https://blog.bitsrc.io/design-patterns-in-typescript-e9f84de40449
作者:Fernando Doglio
譯文地址:https://segmentfault.com/a/1190000025184682
更多程式設計相關知識,請存取:!!
以上就是需要了解的TypeScript的5種設計模式的詳細內容,更多請關注TW511.COM其它相關文章!