Case Studies in GOF Behavioural Patterns: Case Studies in Software Architecture & Design, #4

By Ramki

Learn and consolidate concepts of GOF Design Patterns, the category of Behavioral Patterns here.

 

Each Pattern is explained with a practical real life Case Study.

 

It is platform neutral and hence can be adopted into any programming language / development platform.

 

We normally do not come across such books with deal the concepts with simplicity and yet with full practical bias.

• Language: English
• Publisher: Ramki
• Release date: Dec 28, 2023
• ISBN: 9798223590057

Ramki

Author :   Ramakrishnan N  (Ramki)   Near 50 years of experience in Software Architecture, Enterprise Architecture Design (UML, others) and Patterns (GOF, Microservices and many more), SOA to Microservices to Cloud Native and few State-of-Art technologies.    Consultant and High-end Trainer to many prestigious International Enterprises   Certified in TOGAF 9 and TOGAF 10   Based at Bangalore, India.       Reachable through : [e-mail]

Book preview

COR – Chain of Responsibility

COR – Chain of Responsibility

Behavioural GOF Design Pattern

– Discussion and Case Study

Chain of Responsibility GOF Pattern:

Broadleaf tree We are into Object Oriented Programming. This means our software will have to create an object first and then make use of it to achieve the purpose of the software. Many such objects for different purposes need to be created and based on different classes.

Disaster remote sensing How is an object created ? This question can have a simple answer. Or more complicated answers emerge through Creational Design Patterns listed under GOF category.

Crazy happy sun However, once objects are instantiated, they need to do something between them. Object would invoke methods on other objects and a chain of flow takes place inside the software execution. Object Orientation theory has made the simple and temporary connect-invoke-disconnect kind of relationship as Association.

Silhouette of girl with flowers We already know that each object is assigned some kind of responsibility. Sometimes one object will delegate the responsibility to another object to execute. The Chain of Responsibility is one such Behavioral GOF Pattern.

Logo family When do we need Chain of Responsibility GOF Pattern ?

Auntie on the road Only when we have a genuine concern for de-coupling. This is only when we get into situations where loose coupling technique known as de-coupling is really needed. That too between a number of objects which need to execute in sequence, giving place to a chain flow. Since Chain of Responsibility is a Behavioral Pattern, the issue of runtime chaining (and even change of chaining sequence at runtime) becomes the focus in situations where this Pattern is looked into.

Walking peanut Every association is translating to a run time situation, where one object is invoking a method on the other.

So, there is always a Sender object and a Receiver object. This Sender-Receiver relationship repeats for every chain in the flow.

Sender object invokes the method on the Receiver. May be that it will also pass on a parameter in the invoking process.

Receiver object receives the message. Carries out some task.

What is described above is fine. This is the way the flow takes place between objects, during the execution of any OO software.

Opera We get into the issue of coupling whenever we design an association. Coupling is a kind of measurement. It measures the closeness between two pieces of design. Here we talk about the two classes which participate in the association between the respective objects. 

In strong coupling, the strong degree measure results in changes in design of one class , whenever there is a change in the design of the other class. This is not ideally desired in any software project.

We would rather look for low degree of coupling in each and every association. A low degree of coupling guarantees that changes in one class would not be affecting the design of the other class in the association.

Man in can What does Chain of Responsibility Pattern advocate ? 

Avoid coupling the Sender of a request to its Receiver

by giving more than one object in a chain

a chance to handle the request.

How do we achieve such a de-coupling ?  

Chain the Receiving objects at the end and

pass the request along the chain

allowing many small objects to handle it.

Mr Neutral illustration If such a small in-the-chain object cannot handle a request, it passes it on to the next object in the chain. At the end of the chain, there can be either default of the work by the core Receiver or exceptional behavior may be shown.

Let us take a real life example.

Vector drawing of outdoor home mailbox A letter box (a mailbox where regular post items can be dropped with the destination address and appropriate stamp) is a common scene. The Person who sends the letter simply drops the letter in it.

Open letter vector icon This person has the responsibility to write the letter, seal it in an envelope and write the destination address and affix the stamp.

Postman line man vector clip art The next handler in the scene is the Postal Service employee who will come and collect all the letters in the box at periodical intervals. This person also has clear responsibility of collecting the letters and taking it to the Post Office.

Man on Segway vector How is the first person who writes the letter is coupled to the second person who collects the letters? Each of them are independent of the other, except that the chain action of posting letter is followed by the action of collecting letters.

Man and woman reading vector illustration If we consider the chain, there will be more persons further in the chain, who all will do their respective handling work. The one who sorts the mail in the Post office and groups them destination wise; The one who carries the mails to a central location; The one who again carries mail from the central location to one or more destination locations and so on.

Broken chain Two prominent jargons emerge from this real life situation. These are: chain and responsibility of Handler

Angry postman The chain still has the flexibility. Suppose that one of the letters is addressed to some destination in the same area. Then the chain will change such that the transportation to the destination by a van will be cut short. It will be handed over, by the Sorting Handler to the Mail Delivery Handler.

This itself is an example to reveal the low degree of coupling in this model. It is also clear that it is further the responsibility of each Handler person to decide as to who will be next Handler person.

Chainmal soldier Each processing object contains a set of logic that describes the types of command objects that it can handle, and how to pass off those that it cannot to the next processing object in the chain. A mechanism also exists for adding new processing objects to the end or anywhere in this chain.

––––––––

Case Study of COR Pattern

Super dad day Our Case Study for this topic involves an automated Loan Approval System. A small financial organization accepts applications for small amount of Personal Loans. The person applying for the loan hands over a written application and also a number of supporting documents.

Teacher / Manager vector image The person at the Loan counter checks for the correctness of each document, against its equivalent declaration in the application. For example the age proof is checked against a suitable document and so on. Then this person makes a blind entry of the application details into the screen of a software.

Vector image of monochrome PPT file type sign The first object in the software is the ScreenAcceptor which accepts the data entry of the application and makes it into a LoanApplication object. The responsibility of this object nearly ends here. All it does further is to decide the next handler in the chain.

Penguin admin vector illustration The next object here is the BasicChecker. It checks the application against the very basic requirements such as valid address, age that is legal to borrow and so on. The check logic can be more complicated because if the borrower is of minor age, the application is to be made by a legal guardian and so on. After making the basic checks, and if found fine with all rules, this object decides the next handler in the chain.

Rubber-stamp vector image For Loans above a simple limit the next object is LargeTicketLoanApprover.

Vector graphics of red approved stamp For Loans below the simple limit, the next object is AutoApprover.

The LoanApplication object is the one, though not shown here, that flows in the chain.

A simple flow diagram of the Case Study is shown above. Actually it is a Communication Diagram as per UML 2.0 and is also known as Collaboration Diagram with UML <2.0 versions.

Now let us see the same as a structural set up as recommended by the Chain of Responsibility GOF Pattern. You will realize that the Class Diagram is pretty simple:

We have a simple inheritance hierarchy. The various classes which we discussed above, and which are responsible for carrying out some tasks and then pass it on the next in the chain are shown as four derived classes. The common base class for each one is Handler.

However the only association shown in this Pattern is between the Client and the Handler.

Since each derived Handler will have to carryout some responsible work, we have a common base method: handleRequest(). This will be suitably overridden in each of the derived classes.

How will be chain be established? As we have been discussing so far, it is the responsibility of each Handler object to set the next object in chain. See the method that is being added to the base class design now:

The complete Pattern would appear