Responsibility chain Model _c Language for C + + design Patterns

Objective

Recently the mood is very bad, because the life, because the work, therefore wants to take a few days leave to go to Lijiang to play. A leave application was submitted to the project manager, and my project manager submitted my leave application to the project director, who submitted my leave application to the department manager, and finally the department manager agreed to my application for leave. Yes, a simple vacation application requires such a complex process, which is also necessary for a company to keep it running properly. If the department manager is on leave, who will approve my leave application? At this time, the project supervisor replaces the department manager for approval. A leave application for the approval system has strict requirements. While dealing with this leave approval, each person is like a node in a chain, I do not know my request by who approval, but my request will eventually be someone to deal with. And that kind of behavior is like the responsibility chain pattern I need to summarize today.

What is a responsibility chain model?

In Gof's "design pattern: The basics of reusable object-oriented software", the chain of responsibility model says that multiple objects have the opportunity to process requests, thus avoiding the coupling between the sender and receiver of the request. Connect these objects to a chain until an object has processed it, as shown in the following figure:

For each role, they have their responsibilities; When I submit a vacation application, the project manager needs to decide if he can handle it, and if the vacation exceeds 2 hours, the project manager will not be able to handle it; The project manager submits the request to the project supervisor, who judges the department manager if the department manager is in, The project supervisor could not handle it; Finally, my application for leave went to the department manager and was approved by him personally. It is obvious that the project manager, the project director and the department manager are all likely to process my vacation application, and my request goes along this chain until someone has processed my request.

UML Class Diagram

Handler: Defines an interface for processing requests; Other classes can implement the interface if they need to handle the same request;
Concretehandler: Handles the request it is responsible for, processing the request if it can process it, or forwards the request to its next object that can process the request, so it must be able to access its next object that can handle the same request;
Client: Make a specific request to the processing object.

When a customer submits a request, the request is passed along a chain until a Concretehandler object is responsible for handling it.

Use occasion

1. There are multiple objects that can process a request, and which object handles the request is automatically determined at run time;
2. If you wish to submit a request to one of multiple objects without specifying the recipient explicitly;
3. The collection of objects that can process a request should be dynamically specified.

Code implementation

Copy Code code as follows:

#include <iostream>
using namespace Std;

#define SAFE_DELETE (P) if (p) {DELETE p; p = NULL;}

Class Holidayrequest
{
Public
Holidayrequest (int hour): M_ihour (hour) {}
int Gethour () {return m_ihour;}
Private
int m_ihour;
};

The holiday Request Handler interface
Class Manager
{
Public
virtual bool HandleRequest (holidayrequest *prequest) = 0;
};

Project Manager
Class Pm:public Manager
{
Public
PM (Manager *handler): M_phandler (handler) {}
BOOL HandleRequest (Holidayrequest *prequest)
{
if (Prequest->gethour () <= 2 | | | m_phandler = NULL)
{
cout<< "PM Said:ok." <<endl;
return true;
}
Return M_phandler->handlerequest (prequest);
}
Private
Manager *m_phandler;
};

Department Manager
Class Dm:public Manager
{
Public
DM (Manager *handler): M_phandler (handler) {}
BOOL HandleRequest (Holidayrequest *prequest)
{
cout<< "DM Said:ok." <<endl;
return true;
}

The department manager is in?
BOOL IsIn ()
{
return true;
}
Private
Manager *m_phandler;
};

Project Supervisor
Class Ps:public Manager
{
Public
PS (Manager *handler): M_phandler (handler) {}
BOOL HandleRequest (Holidayrequest *prequest)
{
DM *PDM = dynamic_cast<dm *> (m_phandler);
if (PDM!= NULL)
{
if (Pdm->isin ())
{
Return Pdm->handlerequest (prequest);
}
}
cout<< "PS Said:ok." <<endl;
return true;
}
Private
Manager *m_phandler;
};
int main ()
{
DM *PDM = new DM (NULL);
PS *pps = new PS (PDM);
PM *PPM = new PM (PPS);
Holidayrequest *pholidayrequest = new Holidayrequest (10);
Ppm->handlerequest (pholidayrequest);
Safe_delete (pholidayrequest);

Pholidayrequest = new Holidayrequest (2);
Ppm->handlerequest (pholidayrequest);

Safe_delete (PDM);
Safe_delete (PPS);
Safe_delete (PPM);
Safe_delete (pholidayrequest);
}

Disadvantages

1. Reduce the degree of coupling; the responsibility chain pattern allows an object to not know which object is handling its request. Object only needs to know that the request will be handled correctly. Neither the receiver nor the sender has a clear message, and the object in the chain does not need to know the structure of the chain;

2. Increased flexibility in assigning responsibilities to objects; Responsibility chain gives you more flexibility when assigning responsibilities in an object. You can increase or change the responsibility for handling a request by dynamically adding or modifying the chain at run time;

3. Without guarantee of acceptance, since a request has no clear receiver, there is no guarantee that it will be processed; The request may not be processed until the end of the chain. A request may also not be processed because the chain is not properly configured.

Summarize

The responsibility chain pattern, when implemented, needs to deal with its successor's question, that is, if I do not process the request, who will I send this request to? At the same time, when the responsibility chain pattern is implemented, the shape of its chain is not established and maintained by the responsibility chain itself, but is created by the customer, who specifies the successor of each processor. This greatly improves the flexibility of the responsibility chain. In practice, we can also combine the responsibility chain pattern with the combination pattern, and the parent component of a component can be its successor.