界說
為了不要求發送者與吸收者耦合在一路，讓多個對象都有能夠吸收要求，將這些對象銜接成一條鏈，而且沿著這條鏈傳遞要求，直到有對象處置它為止,職責鏈形式又稱為義務鏈形式，它是一種對象行動型形式。（假如你接觸過異常處置，那末套用異常處置機制可以更好地輿解）。
職責鏈可所以一條直線,也能夠是一個環，還可所以一個樹形構造，不外最多見的職責鏈是直線型，即沿著一條單向的鏈來傳遞要求。鏈上的每個對象都是要求處置者，職責鏈形式可以將要求的處置者組織成一條鏈，並使要求沿著鏈傳遞，由鏈上的處置者對要求停止響應的處置，而客戶端不必關懷要求的處置細節和要求的傳遞，只需將要求發送到鏈上便可，經由過程這類辦法將要求的發送者和要求的處置者解耦，清除兩個腳色間的依附關系，可以自在地組合。

道理構造

上圖闡釋的是職責連形式的完成道理，重要腳色包含：
Handler：籠統處置者。界說出一個處置要求的接口。假如須要，接口可以界說出一個辦法，以設定和前往對下家的援用。這個腳色平日由一個籠統類或接話柄現。
ConcreteHandler： 詳細處置者。詳細處置者接到要求後，可以選擇將要求處置失落，或許將要求傳給下家。因為詳細處置者持有對下家的援用，是以，假如須要，詳細處置者可以拜訪下家。
Client：客戶端
handleRequest：籠統處置者的公用接口，請求每一個鏈式節點都完成這個接口，可以或許處置客戶端發過去的要求數據。
關於每一個鏈式節點，須要知足一下兩個前提：
完成籠統處置者（Handler）所界說的籠統接口，可以或許辨認吸收的要求；
有一個successor，用於把以後不克不及處置的要求轉發傳遞到下一個節點，如斯能力構成一個鏈。（successor是指下一個ConcreteHandler的援用，相當於鏈內外面的next指針）
因為經由過程上述的編程設計，使得要求和處置該要求的對象完整沒有依附關系，由於客戶端乃至不曉得是誰處置了這個要求，如許的話，使得全部鏈式構造很靈巧，可以隨時添加新的的節點，固然也支撐隨便調理節點次序、刪除不用要的節點等等操作。

IOS完成
職責鏈形式的一個很主要的特色是，當客戶收回要求以後，客戶端其實不曉得哪個對象終究處置這個要求，如許體系的更改可以在不影響客戶真個情形下靜態地從新組織和分派義務。

上面給出類構造圖。

從上圖可以看出，當客戶提交一個要求時，要求是沿鏈傳遞直至有一個ConcreteHandler對象擔任處置它。如許做的利益是要求者不消管哪一個對象來處置，橫豎終究是要被某一個對象處置就是了。也就是說吸收者和發送者都沒有對方的明白信息，且鏈中的對象本身也不曉得鏈的構造。成果是職責鏈可簡化對象的互相銜接，它們僅需堅持一個指向厥後繼者的援用，而不需堅持它一切的候選接收者的援用。

這些特色的利益是我們可以隨時增長或修正處置一個要求的構造。加強了給對象指派職責的靈巧性。然則，一個要求極有能夠到了鏈的末尾都得不隨處理，或許由於沒有准確設置裝備擺設而得不隨處理，所以這更須要我們事前斟酌周全。

好的，說了這麼多，照樣老模樣，給年夜家展現一下簡略的表示代碼。

留意：本文一切代碼均在ARC情況下編譯經由過程。

Handlers類接口

#import <Foundation/Foundation.h>

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

Handlers類完成

#import "Handlers.h"

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

ConcreteHandler1類接口

#import "Handlers.h"

@interface ConcreteHandler1:Handlers
-(void)HandleRequest:(int)request;
@end
ConcreteHandler1類完成

#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類接口

#import "Handlers.h"

@interface ConcreteHandler2 :Handlers
@end

ConcreteHandler2類完成

#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類接口

#import "Handlers.h"

@interface ConcreteHandler3 :Handlers
@end

ConcreteHandler3類完成

#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辦法挪用

#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;
}

好啦，代碼展現終了！出工！

小結
行動型形式是對在分歧的對象之間劃分義務和算法的籠統化，行動型形式不只僅存眷類和對象的構造，並且重點存眷它們之間的互相感化。經由過程行動型形式，可以加倍清楚地劃分類與對象的職責，並研討體系在運轉時實例對象之間的交互。行動型形式可以分為類行動型形式和對象行動型形式兩種。職責鏈形式可以免要求發送者與吸收者耦合在一路，讓多個對象都有能夠吸收要求，將這些對象銜接成一條鏈，而且沿著這條鏈傳遞要求，直到有對象處置它為止，它是一種對象行動型形式。
在我們平常應用中，我們也許直接接觸這方面的機遇不多，然則，假如你賣力有研討進程序的一場處置機制，那末你就可以夠發明這類處置機制恰是采取職責鏈的方法處置法式中拋出的異常毛病的。
退職責鏈形式裡，許多對象由每個對象對其下家的援用而銜接起來構成一條鏈。要求在這個鏈上傳遞，直到鏈上的某一個對象決議處置此要求。收回這個要求的客戶端其實不曉得鏈上的哪個對象終究處置這個要求，這使得體系可以在不影響客戶真個情形下靜態地從新組織鏈和分派義務。
職責鏈形式的重要長處在於可以下降體系的耦合度，簡化對象的互相銜接，同時加強給對象指派職責的靈巧性，增長新的要求處置類也很便利；其重要缺陷在於不克不及包管要求必定被吸收，且關於比擬長的職責鏈，要求的處置能夠觸及到多個處置對象，體系機能將遭到必定影響，並且在停止代碼調試時不太便利。

長處：
下降耦合度。
可簡化對象的互相銜接。
加強給對象指派職責的靈巧性。
增長新的要求處置類很便利。

缺陷：
不克不及包管要求必定被吸收。
體系機能將遭到必定影響，並且在停止代碼調試時不太便利（能夠會形成輪回挪用）。

【iOS運用設計形式開辟中職責鏈(義務鏈)形式的完成解析】的相關資料介紹到這裡，希望對您有所幫助！ 提示：不會對讀者因本文所帶來的任何損失負責。如果您支持就請把本站添加至收藏夾哦！