裝飾模式：
1、定義：動態地給一個物件增加一些額外的職責，就增加物件功能來說，裝飾模式比生成子類實作更為靈活
2、模型結構：
(1)抽象構件(Component)：定義一個抽象介面以規范準備接收附加責任的物件
(2)具體構件(ConcreteComponent)：實作抽象構件，通過裝飾角色為其添加一些職責
(3)抽象裝飾類(Decorator)：繼承抽象構件，并包含具體構件的實體，可以通過其子類擴展具體構件的功能
(4)具體裝飾類(ConcreteDecorator)：實作抽象裝飾的相關方法，并給具體構件物件添加附加的責任
3、優點：
(1)裝飾模式與繼承關系的目的都是要擴展物件的功能，但是裝飾模式可以提供比繼承更多的靈活性
(2)可以通過一種動態的方式來擴展一個物件的功能，通過組態檔可以在運行時選擇不同的裝飾器實作不同的行為
(3)通過使用不同的具體裝飾類以及這些裝飾類的排列組合，可以創造出很多不同行為的組合
(4)具體構件類與具體裝飾類可以獨立變化，用戶可以根據需要增加新的具體構件類和具體裝飾類，
在使用時再對其進行組合，原有代碼無須改變，符合“開閉原則”
4、缺點：
(1)使用裝飾模式進行系統設計時將產生很多小物件，這些物件的區別在于它們之間相互連接的方式有所不同，
而不是它們的類或者屬性值有所不同，同時還將產生很多具體裝飾類，
這些裝飾類和小物件的產生將增加系統的復雜度，加大學習與理解的難度
(2)這種比繼承更加靈活機動的特性，也同時意味著裝飾模式比繼承更加易于出錯，排錯也很困難，
對于多次裝飾的物件，除錯時尋找錯誤可能需要逐級排查，較為煩瑣
5、適用環境：
(1)在不影響其他物件的情況下，以動態、透明的方式給單個物件添加職責
(2)需要動態地給一個物件增加功能，這些功能也可以動態地被撤銷
(3)當不能采用繼承的方式對系統進行擴充或者采用繼承不利于系統擴展和維護時
注：不能采用繼承的情況主要有兩類
(1)系統中存在大量獨立的擴展，為支持每一種組合將產生大量的子類，使得子類數目呈爆炸性增長
(2)因為類定義不能繼承（如final類）
// 抽象構件 Componentinterface IPerson { getName(): string;}// 具體構件 ConcreteComponent，繼承抽象構件class Tim implements IPerson { private name: string; getName(): string { this.name = "Tim"; return this.name; }}// 抽象裝飾類 Decorator，繼承抽象構件，并聚合抽象構件class Cloths implements IPerson { protected person: IPerson; constructor(person: IPerson) { this.person = person; } getName(): string { return this.person.getName(); }}class Trousers implements IPerson { protected person: IPerson; constructor(person: IPerson) { this.person = person; } getName(): string { return this.person.getName(); }}// 具體裝飾類 ConcreteDecorator，繼承抽象裝飾類class Suit extends Cloths { private info: string; constructor(person: IPerson) { super(person); } getCloths(): string { this.info = this.person.getName() + "上衣: " + "suit..."; return this.info; }}class Jack extends Cloths { private info: string; constructor(person: IPerson) { super(person); } getCloths(): string { this.info = this.person.getName() + "上衣: " + "jacket..."; return this.info; }}class Pants extends Trousers { private info: string; constructor(person: IPerson) { super(person); } getTrousers(): string { this.info = this.person.getName() + "褲子: " + "pants..."; return this.info; }}class Jean extends Trousers { private info: string; constructor(person: IPerson) { super(person); } getTrousers(): string { this.info = this.person.getName() + "褲子: " + "jean..."; return this.info; }}let tim: IPerson = new Tim();console.log("Get suit");let suit: Suit = new Suit(tim);console.log(suit.getCloths()); // Tim上衣: suit...console.log("Get jean");let jean: Jean = new Jean(tim);console.log(jean.getTrousers()); // Tim褲子: jean...
外觀模式：
1、定義：外部與一個子系統的通信必須通過一個統一的外觀物件進行，為子系統中的一組介面提供一個一致的界面，
外觀模式定義了一個高層介面，這個介面使得這一子系統更加容易使用
2、模型結構：
(1)外觀角色(Facade)：為多個子系統對外提供一個共同的介面
(2)子系統角色(SubSystem)：實作系統的部分功能，客戶可以通過外觀角色訪問它
3、優點：
(1)對客戶屏蔽子系統組件，減少了客戶處理的物件數目并使得子系統使用起來更加容易
(2)降低了子系統與客戶端之間的耦合度，使得子系統的變化不會影響呼叫它的客戶類
(3)降低了大型軟體系統中的編譯依賴性，簡化了系統在不同平臺之間的移植程序，
因為編譯一個子系統不會影響其他的子系統，也不會影響外觀物件
(4)只是提供了一個訪問子系統的統一入口，并不影響用戶直接使用子系統類
4、缺點：
(1)不能很好地限制客戶使用子系統類，如果對客戶訪問子系統類做太多的限制則減少了可變性和靈活性
(2)在不引入抽象外觀類的情況下，增加新的子系統可能需要修改外觀類或客戶端的源代碼，違背了“開閉原則”
5、適用環境：
(1)對分層結構系統構建時，使用外觀模式定義子系統中每層的入口點可以簡化子系統之間的依賴關系
(2)當一個復雜系統的子系統很多時，外觀模式可以為系統設計一個簡單的介面供外界訪問
(3)當客戶端與子系統之間存在很大的聯系時，引入外觀模式可將它們分離，從而提高子系統的獨立性和可移植性
// 子系統類class Light { private name: string; constructor(name) { this.name = name; } open(): void { console.log(this.name + " opened!"); }}class Heater { open(): void { console.log("Heater opened!"); }}// 外觀類，統一操作多個子系統class Facade{ private light1: Light; private light2: Light; private light3: Light; private heater: Heater; constructor() { this.light1 = new Light("light1"); this.light2 = new Light("light2"); this.light3 = new Light("light3"); this.heater = new Heater(); } open(): void { this.light1.open(); this.light2.open(); this.light3.open(); this.heater.open(); }}let facade: Facade = new Facade();facade.open(); // light1 opened! // light2 opened! // light3 opened! // Heater opened!
享元模式：
1、定義：運用共享技術來有効地支持大量細粒度物件的復用，它通過共享已經存在的物件來
大幅度減少需要創建的物件數量、避免大量相似類的開銷，從而提高系統資源的利用率
2、模型結構：
(1)抽象享元類(Flyweight)：是所有的具體享元類的基類，為具體享元規范需要實作的公共介面，
非享元的外部狀態以引數的形式通過方法傳入
(2)具體享元類(ConcreteFlyweight)：實作抽象享元角色中所規定的介面
(3)非共享具體享元類(UnsharedConcreteFlyweight)：不可共享的外部狀態，以引數形式注入具體享元的相關方法中
(4)享元工廠類(FlyweightFactory)：負責創建和管理享元角色，當客戶物件請求一個享元物件時，
享元工廠檢査系統中是否存在符合要求的享元物件，如果存在則提供給客戶；
如果不存在的話，則創建一個新的享元物件
3、優點：
(1)享元模式的優點在于它可以極大減少記憶體中物件的數量，使得相同物件或相似物件在記憶體中只保存一份
(2)享元模式的外部狀態相對獨立，而且不會影響其內部狀態，從而使得享元物件可以在不同的環境中被共享
4、缺點：
(1)享元模式使得系統更加復雜，需要分離出內部狀態和外部狀態，這使得程式的邏輯復雜化
(2)讀取享元模式的外部狀態會使得運行時間稍微變長
注：內部狀態是不會隨著環境的改變而改變的可共享部分；外部狀態是指隨環境改變而改變的不可以共享的部分
5、適用環境：
(1)一個系統有大量相同或者相似的物件，由于這類物件的大量使用，造成記憶體的大量耗費
(2)大部分的物件可以按照內部狀態進行分組，且可將不同部分外部化，這樣每一個組只需保存一個內部狀態
(3)由于享元模式需要額外維護一個保存享元的資料結構，所以應當在有足夠多的享元實體時才值得使用享元模式
// 非共享具體享元class Customer { private name: string; constructor(name: string) { this.name = name; } getName(): string { return this.name; }}// 抽象享元類 Flyweight，書本interface Book { cell(customer: Customer): void;}// 具體享元類 ConcreteFlyweight，書名class BookOrder implements Book { private name: string; constructor(name: string) { this.name = name; } cell(customer: Customer): void { console.log(`Cell a book, named ${this.name} and the customer is ${customer.getName()}`); }}// 享元工廠類 FlyweightFactoryclass BookFactory { // 享元池 private bookPools: Map<string, Book> = new Map<string, Book>(); // 和單例模式結合 private constructor() {} private static factory: BookFactory = new BookFactory(); static getInstance(): BookFactory { return this.factory; } getOrder(bookName: string): Book { let order: Book = null; // 如果存在該書，則從享元池中取出，否則新建一個書物件 if (this.bookPools.has(bookName)) { order = this.bookPools.get(bookName); } else { order = new BookOrder(bookName); this.bookPools.set(bookName, order); } return order; } // 回傳創建物件的數目 getTotalObjs(): number { return this.bookPools.size; }}let orders: Book[] = new Array<Book>();// 確保只有一個工廠物件let factory: BookFactory = BookFactory.getInstance();function takeOrders(bookName: string): void { orders.push(factory.getOrder(bookName));}takeOrders("book1");takeOrders("book2");takeOrders("book4");takeOrders("book2");takeOrders("book3");takeOrders("book1");takeOrders("book5");takeOrders("book1");for (let i in orders) { orders[i].cell(new Customer(`customer ${i}`));}console.log("\n客戶一共買了 " + orders.length + " 本書! "); // 客戶一共買了 8 本書! console.log("共生成了 " + factory.getTotalObjs() + " 個 Book 物件! "); // 共生成了 5 個 Book 物件!
代理模式：
1、定義：給某一個物件提供一個代理，并由代理物件控制對原物件的參考
2、模型結構：
(1)抽象主題角色(Subject)：通過介面或抽象類宣告真實主題和代理物件實作的業務方法
(2)代理主題角色(Proxy)：提供了與真實主題相同的介面，其內部含有對真實主題的參考，
它可以訪問、控制或擴展真實主題的功能
(3)真實主題角色(RealSubject)：實作抽象主題中的具體業務，是代理物件所代表的真實物件，是最終要參考的物件
3、優點：
(1)代理模式能夠協調呼叫者和被呼叫者，在一定程度上降低了系統的耦合度
(2)代理模式在客戶端與目標物件之間起到一個中介作用和保護目標物件的作用
(3)代理物件可以擴展目標物件的功能
4、缺點：
(1)在客戶端和真實主題之間增加了代理物件，因此有些型別的代理模式可能會造成請求的處理速度變慢
(2)實作代理模式需要額外的作業，有些代理模式的實作非常復雜，增加系統復雜度
5、適用環境：
(1)遠程(Remote)代理：為一個位于不同的地址空間的物件提供一個本地的代理物件，
這個不同的地址空間可以是在同一臺主機中，也可是在另一臺主機中，遠程代理又叫做大使(Ambassador)
(2)虛擬(Virtual)代理：如果需要創建一個資源消耗較大的物件，
先創建一個消耗相對較小的物件來表示，真實物件只在需要時才會被真正創建
(3)保護(Protect or Access)代理：控制對一個物件的訪問，可以給不同的用戶提供不同級別的使用權限
(4)智能參考(Smart Reference)代理：當一個物件被參考時，提供一些額外操作，如記錄該物件被呼叫的次數等
(5)緩沖(Cache)代理：為某一個目標操作的結果提供臨時的存盤空間，以便多個客戶端可以共享這些結果
(6)防火墻(Firewall)代理：保護目標不讓惡意用戶接近
(7)同步化(Synchronization)代理：使幾個用戶能夠同時使用一個物件而沒有沖突
(8)Copy-on-Write代理：它是虛擬代理的一種，把復制（克隆）操作延遲到只有在客戶端真正需要時才執行
// 保護代理// 抽象主題角色 Subjectinterface Doc { read(): string;}// 真實主題角色 RealSubjectclass SecretDoc implements Doc { private secret: string = "Secret doc!!!"; private password: string = "123"; read(): string { return this.secret; } checkPsw(password: string): boolean { return this.password === password; }}// 代理主題角色 Proxyclass ProtectionSecretDocProxy implements Doc{ private doc: SecretDoc; private inputPsw: string; constructor(password: string) { this.inputPsw = password; this.doc = new SecretDoc(); } // 判斷密碼是否正確 checkPassword(): boolean { return this.doc.checkPsw(this.inputPsw); } read(): string { if (this.checkPassword()) { return this.doc.read(); } return "Password is wrong!"; }}let userProxy1: ProtectionSecretDocProxy = new ProtectionSecretDocProxy("123");console.log("User1 get: " + userProxy1.read()); // User1 get: Secret doc!!!let userProxy2: ProtectionSecretDocProxy = new ProtectionSecretDocProxy("234");console.log("User2 get: " + userProxy2.read()); // User2 get: Password is wrong!
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/42122.html
標籤：設計模式
上一篇：結構型設計模式（上）
下一篇：設計模式-行為型-狀態模式