Implementation of responsibility chain (liability chain) model in development of IOS application design pattern _ios

Defined
to avoid coupling the sender of the request with the receiver, make it possible for multiple objects to receive requests, connect these objects to a chain, and pass the request along this chain until the object handles it, the responsibility chain pattern is also called the responsibility chain pattern, which is an object behavior pattern. (If you are exposed to exception handling, the exception handling mechanism can be better understood).
A chain of responsibilities can be a straight line, a loop, or a tree structure, but the most common chain of responsibility is a straight line, that is, passing a request along a one-way chain. Each object on the chain is a request handler, the responsibility chain pattern can organize the requested processor into a chain, and the request is routed along the chain, and the request is handled by the processor on the chain, and the client does not care about the processing details of the request and the delivery of the request, just send the request to the chain. This method is used to decouple the sender of the request and the requested processor, eliminating the dependencies between the two roles and being able to combine them freely.

Principle Structure

The diagram above illustrates the implementation principle of the responsibility-attached pattern, which includes:
Handler: Abstract processor. Defines an interface for processing requests. If necessary, the interface can define a method to set and return references to the home. This role is usually implemented by an abstract class or interface.
Concretehandler: Specific processor. When a specific processor receives a request, it may choose to dispose of the request or pass the request to the following. Because the specific processor holds the reference to the homes, therefore, if necessary, the specific processor can visit the homes.
Client: Clients
HandleRequest: The common interface of the abstract processor requires that each chain node implement this interface to handle the request data sent by the client.
For each chain node, you need to meet two conditions:
The abstract interface defined by the abstract processor (Handler) is implemented to recognize the received request;
There is a successor that is used to forward requests that are not currently processed to the next node to form a chain. (successor refers to the next Concretehandler reference, which is equivalent to the next pointer in the list)
Because of the above programming design, the object that requests and processes the request is completely independent, because the client does not even know who handled the request, so that the entire chain structure is very flexible, you can add new nodes at any time, of course, also support the arbitrary Adjustment node order, delete unnecessary nodes and so on.

iOS implementation
a very important feature of the responsibility chain pattern is that when a client makes a request, the client does not know which object is ultimately handling the request, so the system's changes can be dynamically organized and assigned to the responsibility without affecting the client.

The class structure diagram is given below.

As you can see from the diagram above, when a customer submits a request, the request is passed along the chain until a Concretehandler object is responsible for processing it. The advantage of doing this is that the requester does not have to control which object to process, anyway, it is ultimately to be handled by an object. That is to say, neither the recipient nor the sender has a clear message, and the object in the chain does not know the structure of the chain. The result is that the responsibility chain simplifies the mutual connection of objects, and they only need to keep a reference to the successor, without having to keep all of its candidate recipients ' references.

The advantage of these features is that we can add or modify the structure at any time to process a request. Enhances the flexibility of assigning responsibilities to objects. However, a request is most likely to go to the end of the chain can not be processed, or because it is not properly configured without processing, so this requires us to consider comprehensively.

OK, say so much, still the same as usual, show us a simple schematic code.

Note: All of the code in this article is compiled in an arc environment.

Handlers class interface

Copy Code code as follows:

#import <Foundation/Foundation.h>

@interface handlers:nsobject{
Handlers *mysuccessor;
}
-(void) Setsuccessor: (handlers*) successor;
-(void) HandleRequest: (int) request;
@end

Handlers class implementation

Copy Code code as follows:

#import "Handlers.h"

@implementation handlers
-(void) Setsuccessor: (Handlers *) successor{
Mysuccessor = successor;
}
-(void) HandleRequest: (int) request{
Return
}
@end

ConcreteHandler1 class Interface

Copy Code code as follows:

#import "Handlers.h"

@interface Concretehandler1:handlers
-(void) HandleRequest: (int) request;
@end
ConcreteHandler1 class implementation

#import "ConcreteHandler1.h"

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

ConcreteHandler2 class Interface

Copy Code code as follows:

#import "Handlers.h"

@interface Concretehandler2:handlers
@end

ConcreteHandler2 class implementation

Copy Code code as follows:

#import "ConcreteHandler2.h"

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

ConcreteHandler3 class Interface

Copy Code code as follows:

#import "Handlers.h"

@interface Concretehandler3:handlers
@end

ConcreteHandler3 class implementation

Copy Code code as follows:

#import "ConcreteHandler3.h"

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

Main method call

Copy Code code as follows:

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

All right, code is over! Wrap

Summary
behavioral pattern is the abstraction of responsibility and algorithm between different objects, and the behavioral pattern not only focuses on the structure of classes and objects, but also focuses on the interaction between them. Through behavioral patterns, the responsibilities of classes and objects can be divided more clearly, and the interaction between the system at Run-time instance objects is studied. Behavioral pattern can be divided into two types: class behavior pattern and object behavior pattern. The responsibility chain model avoids the request sender being coupled to the receiver, making it possible for multiple objects to receive requests, connect the objects into a chain, and pass the request along the chain until an object has processed it, an object-behavioral pattern.
In our daily use, we may not have much direct access to this area, but if you are serious about the process of sequencing a processing mechanism, then you can find that the processing mechanism is to use the responsibility chain to handle the exception thrown in the process of abnormal errors.
In the chain of responsibilities, many objects are connected by each object's reference to their house to form a chain. The request is passed on this chain until an object on the chain decides to process the request. The client issuing the request does not know which object on the chain ultimately handles the request, allowing the system to dynamically rearrange the chain and assign responsibility without affecting the client.
The main advantage of the responsibility chain model is that it can reduce the coupling degree of the system, simplifying the mutual connection of objects while enhancing the flexibility of assigning responsibilities to objects, and adding new request processing classes is also convenient; The main disadvantage is that the request must not be received, and for a longer chain of responsibility, the processing of the request may involve multiple processing objects. System performance will be affected and is not convenient for code debugging.

Advantages:
reduce the coupling degree.
Simplifies the mutual connection of objects.
Enhances the flexibility to assign responsibilities to objects.
It is convenient to add new request processing classes.

Disadvantages:
there is no guarantee that the request will be received.
System performance will be affected, and it may be inconvenient to debug code (which might cause a circular call).