設計模式系列10--裝飾者模式

image

大部分公司都有銷售團隊，假設老闆給你佈置了一個任務，讓你按照下面的要求開發一套程序來計算銷售團隊每月的工資。

• 每一個人當月業務獎金 = 當月銷售額 * 3%
• 每一個人的累積獎金 = 總的回款額 * 0.1%
• 銷售經理的團隊獎金 = 團隊總銷售額 * 1%

每一個人的工資就是基本工資加上獎金，那麼按照常規模式咱們來看下如何讓實現。

#import "calculateBonus.h"

@implementation calculateBonus

-(NSInteger)calculateSalary:(NSInteger)monthSales  sumSales:(NSInteger)sumSales isManager:(BOOL)manager{
    //基本工資都是8000
    NSInteger salary = 8000;
    salary += [self monthBonus:monthSales];
    salary += [self sumBonus:sumSales];
    if (manager) {
        salary += [self groupBonus];
    }

    return salary;

}


//當月獎金
-(NSInteger)monthBonus:(NSInteger)monthSales{
    return monthSales * 0.003;
}


//累積獎金
-(NSInteger)sumBonus:(NSInteger)sumSales{
    return  sumSales * 0.001;
}

//團隊獎金
-(NSInteger)groupBonus{
    //簡單起見，團隊的銷售總額設置爲100000
    return 100000 * 0.01;
}
@end複製代碼

測試下：

calculateBonus *calculate = [calculateBonus new];
NSInteger salary1 = [calculate calculateSalary:12222 sumSales:12000 isManager:YES];
NSLog(@"經理工資：%zd", salary1);

NSInteger salary2 = [calculate calculateSalary:21333 sumSales:23111 isManager:NO];
NSLog(@"員工甲：%zd", salary2);

NSInteger salary3 = [calculate calculateSalary:22113 sumSales:11222 isManager:NO];
NSLog(@"員工乙：%zd", salary3);複製代碼

輸出：

2016-12-14 08:57:58.600 裝飾者模式[64313:1880733] 經理工資：9048
2016-12-14 08:57:58.601 裝飾者模式[64313:1880733] 員工甲：8086
2016-12-14 08:57:58.601 裝飾者模式[64313:1880733] 員工乙：8077
Program ended with exit code: 0複製代碼

看起來運行良好，好，該來的仍是來了，該需求。

如今要增長一個環比獎金：就是本月銷售額比上月又增長，而後達到必定比例，就會有獎金，增長越多，獎金比率越高。你說這還不簡單，再加一個環比獎金計算方法不就是了。那麼若是工資計算的方式也換了呢？不一樣級別的人員或者員工的計算獎金的方式也換了呢？

假設

• 甲的總工資 = 基本工資 + 當月銷售獎金 + 環比獎金

• 乙的工資 = 基本工資 + 環比獎金

• 丙的工資 = 基本工資 + 當月銷售獎金

• 丁的工資 = 基本工資 + 環比獎金 + 團隊獎金

後面再給你制定十幾種不一樣的計算方式，崩潰了沒有？按照上面的寫法，那麼每一種總工資計算方式你都要寫一種方法，再假設這些人的總工資計算方式每一個季度還會有調整，你怎麼辦，接着改？

仔細分析下上面的需求，總工資的計算有兩部分：基本工資加上各類獎金，基本工資是固定的，麻煩的地方就在於獎金的計算方式是動態變化的，有各類各樣的組合方式。按照設計模式的思想：封裝變化，這裏變化的部分是獎金的組合方式，那麼咱們就把這部分封裝起來。

咱們能夠採起這樣的方式，把每張獎金的計算方式都單獨成類，而後須要用到哪一種獎金計算，就把這個獎金計算和基本工資組合起來，須要多少種獎金計算方式，就組合多少種。這樣實現起來，是否是很是靈活？之後你想修改或者增長減小獎金計算方式，只須要修改或者增長減小一個獎金計算方式就能夠了，至於每一個人的總工資計算方式各不相同，就更簡單了，交給客戶端自由組合。

總結起來就是以下三個要求：

• 獎金計算方式要靈活，能夠動態增長或者減小

• 能夠動態組合獎金計算方式

要實現上面的功能，就要清楚咱們今天的豬腳：裝飾器模式。

下面來認識下這位仁兄

---

定義

動態地給一個對象添加一些額外的職責。就增長功能來講, 裝飾模式比生成子類更爲靈活。

通常咱們在給一個本來的類添加功能的時候，都會想到使用繼承，在原有的類上擴展新的功能，可是繼承有一個很是大的缺點：和父類耦合性過高。若是後續須要添加或者減小功能，就不得不每次都要修改子類，並且若是修改了父類，對子類的影響也很是大。

因此咱們通常優先考慮使用組合來實現功能的擴展，這也是設計模式的一個原則：多用組合，少用繼承。裝飾器模式就是實現組合功能的一種方式，它能夠透明的給本來的類增長或者減小功能，並且能夠把多個功能組合在一塊兒，他不會改變原有類的功能，只是在原來功能的基礎上加上一些新功能，而這些操做被裝飾對象是絕不知情的。

好比上面的計算總工資，原有的對象是基本工資，可是須要在基本工資的基礎上加上各類獎金，也就是給基本工資擴展了功能，可是基本工資這個原有功能是不會改變的，只是給他加上了各類各樣的獎金，豐富了它的功能，最後算出來的仍是工資，也就是保持原有的類型（整數型）不改變，這點要切記。

---

UML結構如及說明

image

實現裝飾器模式要注意以下幾點：

1.接口的一致性

裝飾對象的接口必須與它所裝飾的Component的接口是一致的,所以,全部的concreteDecorator類必須有一個公共的父類

2.省略抽象的Decorator類

當你僅須要添加一個職責時,沒有必要定義抽象Decorator類。你經常須要處理現存的類層次結構而不是設計一個新系統,這時你能夠把Decorator向Component轉發請求的職責合併到ConcreteDecorator中。

3.保持Component類的簡單性

爲了保證接口的一致性,組件和裝飾必須有一個公共的Component父類。所以保持這個類的簡單性是很重要的；即，它應集中於定義接口而不是存儲數據。對數據表示的定義應延遲到子類中，不然Component類會變得過於複雜和龐大,於是難以大量使用。賦予Component太多的功能也使得,具體的子類有一些它們並不須要的功能的可能性大大增長。

4.改變對象外殼與改變對象內核

咱們能夠將Decorator看做一個對象的外殼,它能夠改變這個對象的行爲。另一種方法是改變對象的內核。例如,Strategy模式就是一個用於改變內核的很好的模式。
當Component類本來就很龐大時,使用Decorator模式代價過高,Strategy模式相對更好一些。在Strategy模式中，組件將它的一些行爲轉發給一個獨立的策略對象，咱們能夠替換strategy對象，從而改變或擴充組件的功能。

image

---

代碼實現

一、定義抽象基類

先定義一個抽象基類，工資類和獎金計算方式類都繼承自這個類，該類定義了一個公開接口，用於計算獎金

#import <Foundation/Foundation.h>

@interface component : NSObject
-(NSInteger)calculateSalary:(NSInteger)monthSales  sumSales:(NSInteger)sumSales;
@end

=================複製代碼

二、定義工資類（被裝飾對象）

#import "component.h"

@interface concreteComponent : component

@end

======================

//被裝飾對象，基本工資

#import "concreteComponent.h"

@implementation concreteComponent

-(NSInteger)calculateSalary:(NSInteger)monthSales  sumSales:(NSInteger)sumSales{
    //基本工資8000
    return 8000;
}

@end複製代碼

三、定義抽象裝飾器

定義一個抽象裝飾器，繼承自抽象基類component，每一個具體的裝飾器繼承自該類，該類主要作一些初始化工做

#import "component.h"

@interface Decorator : component
@property(strong,nonatomic)component *components;
- (instancetype)initWithComponet:(component *)component;
@end

=================

#import "Decorator.h"

@implementation Decorator
- (instancetype)initWithComponet:(component *)component
{
    self = [super init];
    if (self) {
        self.components = component;
    }
    return self;
}

-(NSInteger)calculateSalary:(NSInteger)monthSales sumSales:(NSInteger)sumSales{
    return [self.components calculateSalary:monthSales sumSales:sumSales];
}
@end複製代碼

四、具體裝飾器

每個月銷售獎金裝飾器

#import "Decorator.h"

@interface monthBonusDecorator : Decorator

@end

==================


#import "monthBonusDecorator.h"

@implementation monthBonusDecorator

-(NSInteger)calculateSalary:(NSInteger)monthSales sumSales:(NSInteger)sumSales{
    NSInteger salary = [self.components calculateSalary:monthSales sumSales:sumSales];
    NSInteger bonus = monthSales * 0.03;
    NSLog(@"當月銷售獎金：%zd", bonus);
    return salary += bonus;
}
@end複製代碼

累積獎金裝飾器

#import "Decorator.h"

@interface sumBonusDecatorator : Decorator

@end

================

#import "sumBonusDecatorator.h"

@implementation sumBonusDecatorator

-(NSInteger)calculateSalary:(NSInteger)monthSales sumSales:(NSInteger)sumSales{
    NSInteger salary = [self.components calculateSalary:monthSales sumSales:sumSales];
    NSInteger bonus = sumSales * 0.01;
    NSLog(@"累積銷售獎金：%zd", bonus);
    return salary += bonus;
}

@end複製代碼

團隊獎金裝飾器

#import "Decorator.h"

@interface groupBonusDecorator : Decorator

@end

=================

#import "groupBonusDecorator.h"

@implementation groupBonusDecorator
-(NSInteger)calculateSalary:(NSInteger)monthSales sumSales:(NSInteger)sumSales{
    NSInteger salary = [self.components calculateSalary:monthSales sumSales:sumSales];
    NSInteger bonus = 100000 * 0.01;
    NSLog(@"團隊獎金：%zd", bonus);
    return salary += bonus;
}
@end複製代碼

五、測試

//基本工資，被裝飾對象
        component *c1 = [concreteComponent new];

        //裝飾器
        Decorator *d1 = [[monthBonusDecorator alloc]initWithComponet:c1];
        Decorator *d2 = [[sumBonusDecatorator alloc]initWithComponet:d1];
        NSInteger salary1 = [d2 calculateSalary:10000 sumSales:12212];
        NSLog(@"\n獎金組合方式：當月銷售獎金 + 累積銷售獎金 \n 總工資 = %zd", salary1);

        NSLog(@"\n=============================================================================");

        Decorator *d3 = [[monthBonusDecorator alloc]initWithComponet:c1];
        Decorator *d4 = [[sumBonusDecatorator alloc]initWithComponet:d3];
        Decorator *d5 = [[groupBonusDecorator alloc]initWithComponet:d4];
        NSInteger salary2 = [d5 calculateSalary:12100 sumSales:12232];
        NSLog(@"\n獎金組合方式：當月銷售獎金 + 累積銷售獎金 + 團隊獎金 \n 總工資 = %zd", salary2);


        NSLog(@"\n=============================================================================");

        Decorator *d6 = [[monthBonusDecorator alloc]initWithComponet:c1];
        Decorator *d7 = [[groupBonusDecorator alloc]initWithComponet:d6];
        NSInteger salary3 = [d7 calculateSalary:23111 sumSales:231111];
        NSLog(@"\n獎金組合方式：當月銷售獎金 + 團隊獎金 \n 總工資 = %zd", salary3);複製代碼

輸出以下

2016-12-14 10:34:31.280 裝飾者模式[64586:1944336] 當月銷售獎金：300
2016-12-14 10:34:31.280 裝飾者模式[64586:1944336] 累積銷售獎金：122
2016-12-14 10:34:31.280 裝飾者模式[64586:1944336] 
獎金組合方式：當月銷售獎金 + 累積銷售獎金 
 總工資 = 8422

=============================================================================
2016-12-14 10:34:31.280 裝飾者模式[64586:1944336] 當月銷售獎金：363
2016-12-14 10:34:31.280 裝飾者模式[64586:1944336] 累積銷售獎金：122
2016-12-14 10:34:31.280 裝飾者模式[64586:1944336] 團隊獎金：1000
2016-12-14 10:34:31.280 裝飾者模式[64586:1944336] 
獎金組合方式：當月銷售獎金 + 累積銷售獎金 + 團隊獎金 
 總工資 = 9485

=============================================================================
2016-12-14 10:34:31.281 裝飾者模式[64586:1944336] 當月銷售獎金：693
2016-12-14 10:34:31.281 裝飾者模式[64586:1944336] 團隊獎金：1000
2016-12-14 10:34:31.281 裝飾者模式[64586:1944336] 
獎金組合方式：當月銷售獎金 + 團隊獎金 
 總工資 = 9693複製代碼

六、小結

從上面的測試能夠看出，不論是使用何種獎金組合方式，只須要調用對應的裝飾器便可，很是靈活。經過上面的代碼咱們看到，裝飾器是一層層包裹的，基本工資被月工資裝飾器包裹，月工資裝飾器被累積獎金裝飾器包裹，累積裝飾器被團隊獎金裝飾器包裹，當調用計算獎金的公式的時候，就會按照順序層層遞歸調用每一個裝飾器的功能，到最後算出總工資，咱們來用示意圖看看調用過程。

因爲每一個裝飾器之間是徹底獨立的，因此咱們可使用任何咱們想要的方式去組合這些裝飾器，好比屢次重複調用同一個裝飾器，調換裝飾器的順序等等。

image

---

適用性

在以下狀況能夠考慮使用對象組合

• 在不影響其餘對象的狀況下,以動態、透明的方式給單個對象添加職責。

• 處理那些能夠撤消的職責。

• 當不能採用生成子類的方法進行擴充時
  一種狀況是，可能有大量獨立的擴展，爲支持每一種組合將產生大量的子類，使得子類數目呈爆炸性增加。另外一種狀況多是由於類定義被隱藏，或類定義不能用於生成子類。

---

優缺點

1. 比繼 承 更 靈 活

   與 對 象 的 靜 態 繼 承 ( 多 重 繼 承 ) 相 比 , D e c o r a t o r 模 式 提 供 了 更 加
   靈活的向對象添加職責的方式。能夠用添加和分離的方法,用裝飾在運行時刻增長和刪除職 責。相比之下,繼承機制要求爲每一個添加的職責建立一個新的子類。這會產生許多新的類,而且會增長系統的複雜度。此外,爲一 個特定的 C o m p o n e n t 類 提 供 多 個 不 同 的 D e c o r a t o r 類 , 這 就 使 得 你 可 以 對 一 些 職 責 進 行 混 合 和 匹配。
   使用 D e c o r a t o r 模式能夠很容易地重複添加一個特性。

2. 避 免 了高層次類 有 太 多 的 特 徵

   D e c o r a t o r模 式 提 供 了 一 種 「 即 用 即 付 」 的 方 法來添加職責。它並不試圖在一個複雜的可定製的類中支持全部可預見的特徵，相反，你可 以定義一個簡單的類，而且用 D e c o r a t o r 類 給 它 逐 漸 地 添 加 功 能 。 可 以 從 簡 單 的 部 件 組 合 出 復 雜的功能。這樣，應用程序沒必要爲不須要的特徵付出代價。同時也更易於不依賴於 D e c o r a t o r 所擴展(甚至是不可預知的擴展)的類而獨立地定義新類型的 D e c o r a t o r 。 擴 展 一 個 復 雜 類 的 時候,極可能會暴露與添加的職責無關的細節。

3. 產生 許 多 小 對 象

   採用 D e c o r a t o r 模 式 進 行 系 統 設 計 往 往 會 產 生 許 多 看 上 去 類 似 的 小 對 象 , 這些對象僅僅在他們相互鏈接的方式上有所不一樣,而不是它們的類或是它們的屬性值有所不 同。儘管對於那些瞭解這些系統的人來講,很容易對它們進行定製,可是很難學習這些系統, 排錯也很困難。

---

裝飾器和AOP

關於面向切換編程的具體解釋看這裏

百度百科AOP解釋

AOP通常用來實現以下功能：日誌記錄，性能統計，安全控制，事務處理，異常處理等等。將日誌記錄，性能統計，安全控制，事務處理，異常處理等代碼從業務邏輯代碼中劃分出來，經過對這些行爲的分離，咱們但願能夠將它們獨立到非業務邏輯的方法中，進而改變這些行爲的時候不影響業務邏輯的代碼。

看上面的描述就知道，裝飾器就是一個很好實現AOP的方式，由於裝飾器就是在不改變原有功能的前提下對其進行透明擴展的。

咱們目前有一個鴨子類，實現呱呱叫的一個方法，如今我但願在不改變原有功能的狀況下，統計鴨子叫了多少次，這就是AOP中的日誌記錄功能，咱們可使用裝飾器模式來實現，具體代碼我就不貼了，直接看最後的demo。

---

裝飾器在iOS中的運用

咱們應該用過一些圖片處理app，能夠給圖片加上各類各樣的濾鏡或者裁剪旋轉圖片等等功能，其實這些也可使用裝飾器來實現，能夠把每一個功能都實現爲一個裝飾器，而後用戶選擇使用什麼功能，就給圖片加上對應的裝飾器去作處理，這樣作是否是很是靈活？

其實在iOS裏面已經爲咱們提供了相似裝飾器模式的功能的方法：category。category也能夠透明的爲一個類添加方法，下面我就使用一個小demo來演示如何使用category和裝飾者模式分別來實現圖片的選擇和陰影效果。具體見demo。

---

demo下載

裝飾者模式Demo

鴨子叫聲計數器Demo

裝飾者模式和category Demo