国产探花免费观看_亚洲丰满少妇自慰呻吟_97日韩有码在线_资源在线日韩欧美_一区二区精品毛片,辰东完美世界有声小说,欢乐颂第一季,yy玄幻小说排行榜完本

首頁 > 系統(tǒng) > iOS > 正文

iOS應(yīng)用設(shè)計模式開發(fā)中職責(zé)鏈(責(zé)任鏈)模式的實現(xiàn)解析

2019-10-21 18:55:10
字體:
供稿:網(wǎng)友
這篇文章主要介紹了iOS應(yīng)用設(shè)計模式開發(fā)中職責(zé)鏈模式的相關(guān)實現(xiàn)解析,示例代碼為傳統(tǒng)的Objective-C,需要的朋友可以參考下
 

定義
為了避免請求發(fā)送者與接收者耦合在一起,讓多個對象都有可能接收請求,將這些對象連接成一條鏈,并且沿著這條鏈傳遞請求,直到有對象處理它為止,職責(zé)鏈模式又稱為責(zé)任鏈模式,它是一種對象行為型模式。(如果你接觸過異常處理,那么套用異常處理機制可以更好地理解)。
職責(zé)鏈可以是一條直線,也可以是一個環(huán),還可以是一個樹形結(jié)構(gòu),不過最常見的職責(zé)鏈?zhǔn)侵本€型,即沿著一條單向的鏈來傳遞請求。鏈上的每一個對象都是請求處理者,職責(zé)鏈模式可以將請求的處理者組織成一條鏈,并使請求沿著鏈傳遞,由鏈上的處理者對請求進行相應(yīng)的處理,而客戶端無須關(guān)心請求的處理細節(jié)以及請求的傳遞,只需將請求發(fā)送到鏈上即可,通過這種方法將請求的發(fā)送者和請求的處理者解耦,消除兩個角色間的依賴關(guān)系,可以自由地組合。

原理結(jié)構(gòu)

iOS應(yīng)用開發(fā),設(shè)計模式

上圖闡釋的是職責(zé)連模式的實現(xiàn)原理,主要角色包括:
Handler:抽象處理者。定義出一個處理請求的接口。如果需要,接口可以定義出一個方法,以設(shè)定和返回對下家的引用。這個角色通常由一個抽象類或接口實現(xiàn)。
ConcreteHandler: 具體處理者。具體處理者接到請求后,可以選擇將請求處理掉,或者將請求傳給下家。由于具體處理者持有對下家的引用,因此,如果需要,具體處理者可以訪問下家。
Client:客戶端
handleRequest:抽象處理者的公用接口,要求每個鏈?zhǔn)焦?jié)點都實現(xiàn)這個接口,能夠處理客戶端發(fā)過來的請求數(shù)據(jù)。
對于每個鏈?zhǔn)焦?jié)點,需要滿足一下兩個條件:
實現(xiàn)抽象處理者(Handler)所定義的抽象接口,能夠識別接收的請求;
有一個successor,用于把當(dāng)前不能處理的請求轉(zhuǎn)發(fā)傳遞到下一個節(jié)點,如此才能形成一個鏈。(successor是指下一個ConcreteHandler的引用,相當(dāng)于鏈表里面的next指針)
由于通過上述的編程設(shè)計,使得請求和處理該請求的對象完全沒有依賴關(guān)系,因為客戶端甚至不知道是誰處理了這個請求,這樣的話,使得整個鏈?zhǔn)浇Y(jié)構(gòu)很靈活,可以隨時添加新的的節(jié)點,當(dāng)然也支持隨意調(diào)節(jié)節(jié)點順序、刪除不必要的節(jié)點等等操作。

iOS實現(xiàn)
職責(zé)鏈模式的一個很重要的特點是,當(dāng)客戶發(fā)出請求之后,客戶端并不知道哪一個對象最終處理這個請求,這樣系統(tǒng)的更改可以在不影響客戶端的情況下動態(tài)地重新組織和分配責(zé)任。

下面給出類結(jié)構(gòu)圖。

iOS應(yīng)用開發(fā),設(shè)計模式

從上圖可以看出,當(dāng)客戶提交一個請求時,請求是沿鏈傳遞直至有一個ConcreteHandler對象負責(zé)處理它。這樣做的好處是請求者不用管哪個對象來處理,反正最終是要被某一個對象處理就是了。也就是說接收者和發(fā)送者都沒有對方的明確信息,且鏈中的對象自己也不知道鏈的結(jié)構(gòu)。結(jié)果是職責(zé)鏈可簡化對象的相互連接,它們僅需保持一個指向其后繼者的引用,而不需保持它所有的候選接受者的引用。

這些特點的好處是我們可以隨時增加或修改處理一個請求的結(jié)構(gòu)。增強了給對象指派職責(zé)的靈活性。但是,一個請求極有可能到了鏈的末端都得不到處理,或者因為沒有正確配置而得不到處理,所以這更需要我們事先考慮全面。

好的,說了這么多,還是老樣子,給大家展示一下簡單的示意代碼。

注意:本文所有代碼均在ARC環(huán)境下編譯通過。

Handlers類接口

復(fù)制代碼代碼如下:

#import <Foundation/Foundation.h>

 

@interface Handlers :NSObject{
    Handlers *mySuccessor;
}
-(void)SetSuccessor:(Handlers*)successor;
-(void)HandleRequest:(int)request;
@end


Handlers類實現(xiàn)
復(fù)制代碼代碼如下:

#import "Handlers.h"

 

@implementation Handlers
-(void)SetSuccessor:(Handlers *)successor{
    mySuccessor = successor;
}
-(void)HandleRequest:(int)request{
    return;
}
@end


ConcreteHandler1類接口
復(fù)制代碼代碼如下:

#import "Handlers.h"

 

@interface ConcreteHandler1:Handlers
-(void)HandleRequest:(int)request;
@end
ConcreteHandler1類實現(xiàn)

#import "ConcreteHandler1.h"

@implementation ConcreteHandler1
-(void)HandleRequest:(int)request{
    if (request >=0 && request <10) {
        NSLog(@"ConcreteHandler1處理%d", request);
    }
    else if (mySuccessor !=nil) {
            [mySuccessor HandleRequest:request];
    }
}
@end


ConcreteHandler2類接口
復(fù)制代碼代碼如下:

#import "Handlers.h"

 

@interface ConcreteHandler2 :Handlers
@end


ConcreteHandler2類實現(xiàn)
復(fù)制代碼代碼如下:

#import "ConcreteHandler2.h"

 

@implementation ConcreteHandler2
-(void)HandleRequest:(int)request{
    if (request >=10 && request <20) {
        NSLog(@"ConcreteHandler2處理%d", request);
    }
    else if(mySuccessor !=nil) {
        [mySuccessor HandleRequest:request];
    }
}
@end


ConcreteHandler3類接口
復(fù)制代碼代碼如下:

#import "Handlers.h"

 

@interface ConcreteHandler3 :Handlers
@end


ConcreteHandler3類實現(xiàn)
復(fù)制代碼代碼如下:

#import "ConcreteHandler3.h"

 

@implementation ConcreteHandler3
-(void)HandleRequest:(int)request{
    if (request >=20 && request <30) {
        NSLog(@"ConcreteHandler3處理%d", request);
    }
    else if (mySuccessor !=nil) {
        [mySuccessor HandleRequest:request];
    }
}
@end


Main方法調(diào)用
復(fù)制代碼代碼如下:

#import <Foundation/Foundation.h>

 

int main(int argc,const char * argv[])
{
    @autoreleasepool{
        Handlers *h1 = [[ConcreteHandler1 alloc]init];
        Handlers *h2 = [[ConcreteHandler2 alloc]init];
        Handlers *h3 = [[ConcreteHandler3 alloc]init];
        [h1 SetSuccessor:h2];
        [h2 SetSuccessor:h3];
        int requests[] = {2,5,14,22,18,3,27,20};
        for (int i =0; i <8; i++) {
            [h1 HandleRequest:requests[i]];
        }
    }
    return 0;
}


好啦,代碼展示完畢!收工!

 

小結(jié)
行為型模式是對在不同的對象之間劃分責(zé)任和算法的抽象化,行為型模式不僅僅關(guān)注類和對象的結(jié)構(gòu),而且重點關(guān)注它們之間的相互作用。通過行為型模式,可以更加清晰地劃分類與對象的職責(zé),并研究系統(tǒng)在運行時實例對象之間的交互。行為型模式可以分為類行為型模式和對象行為型模式兩種。職責(zé)鏈模式可以避免請求發(fā)送者與接收者耦合在一起,讓多個對象都有可能接收請求,將這些對象連接成一條鏈,并且沿著這條鏈傳遞請求,直到有對象處理它為止,它是一種對象行為型模式。
在我們?nèi)粘J褂弥校覀兓蛟S直接接觸這方面的機會不多,但是,如果你認真有研究過程序的一場處理機制,那么你就能夠發(fā)現(xiàn)這種處理機制正是采用職責(zé)鏈的方式處理程序中拋出的異常錯誤的。
在職責(zé)鏈模式里,很多對象由每一個對象對其下家的引用而連接起來形成一條鏈。請求在這個鏈上傳遞,直到鏈上的某一個對象決定處理此請求。發(fā)出這個請求的客戶端并不知道鏈上的哪一個對象最終處理這個請求,這使得系統(tǒng)可以在不影響客戶端的情況下動態(tài)地重新組織鏈和分配責(zé)任。
職責(zé)鏈模式的主要優(yōu)點在于可以降低系統(tǒng)的耦合度,簡化對象的相互連接,同時增強給對象指派職責(zé)的靈活性,增加新的請求處理類也很方便;其主要缺點在于不能保證請求一定被接收,且對于比較長的職責(zé)鏈,請求的處理可能涉及到多個處理對象,系統(tǒng)性能將受到一定影響,而且在進行代碼調(diào)試時不太方便。

優(yōu)點:
降低耦合度。
可簡化對象的相互連接。
增強給對象指派職責(zé)的靈活性。
增加新的請求處理類很方便。

缺點:
不能保證請求一定被接收。
系統(tǒng)性能將受到一定影響,而且在進行代碼調(diào)試時不太方便(可能會造成循環(huán)調(diào)用)。



注:相關(guān)教程知識閱讀請移步到IOS開發(fā)頻道。
發(fā)表評論 共有條評論
用戶名: 密碼:
驗證碼: 匿名發(fā)表
主站蜘蛛池模板: 汾阳市| 太仆寺旗| 安庆市| 余姚市| 广水市| 竹溪县| 阳泉市| 平江县| 十堰市| 庄浪县| 肥东县| 丰都县| 斗六市| 香河县| 伊吾县| 米林县| 潢川县| 彰武县| 广河县| 临桂县| 吉林市| 玉田县| 招远市| 元氏县| 壤塘县| 休宁县| 富阳市| 增城市| 尼玛县| 拜泉县| 锡林郭勒盟| 威远县| 得荣县| 云梦县| 砀山县| 巩留县| 哈尔滨市| 江孜县| 乌拉特前旗| 五家渠市| 西乌珠穆沁旗|