Have a Request handled by multiple handlers in a chain of responsibility pattern

Question

I was learning design pattern's to implement it in code and I think I found one that I think will work but with one major flaw.

The pattern I ended up on is Chain Of Responsibility Pattern . From what I understand there is a request passed to a single handler which will either handle the request or pass it down the chain.

The only catch I see is it specifies that once one of the handler handles the request the processing stops. I want something that will keep going in chain and give chance for every handler to process the request.

Problem Statement

I am creating an application which will send a invoice to a company and I want to know who all have looked at the invoice and signed off.We need to ensure each department has signed off like accounts,finance etc..The important aspect is just cause 1 department signing it should not end the process which I believe happens in this pattern

It is completely possible that this pattern might not suit me,if that is can you please suggest me a pattern that would. This is not a class project it is just me learning to use pattern's and finding its use it daily life.

Answer 1

I don't know whether to make this an answer or a comment, but:

To me it sounds like you are looking at a Pipeline or Pool moreso than a Chain of responsibility. In a chain, the driving idea is that each link in the chain will either process the data or pass it onto the next link. Then, once a link in the chain does process the data, the chain end.

In a Pipeline, the idea is that all steps will at least look at the data, though they may not actually do any processing given the data. Usually the implicit understanding is that a Pipeline is 'linear-ish'.

In your case that would mean that one department needs to sign off before the next department can sign off. The pipeline also implies that the state of the data may change as it moves along it.

Since in your example it sounds like each department's approval is independent, you could use a Pool. Normally we think of a pool as a pool of threads, but at it's basis a pool can be thought of as a group of independent processes that apply to the same input data with the result of each process being collected and returned in some form of collection of results.

Of course there are some considerations to think about: as soon as any department denies a request, should the system short circuit? Is there complicated business logic at play, is something like department A and C approving​, B denying and department D not casting a vote before a deadline a theoretical state that needs to be handled?

I typed this on a phone before bed so forgive any deficiencies in the answer. I will come back tomorrow and have a look at it and do some cleanup if need be.

Answer 2

Strategy pattern is more suitable to your case.

You need to decide what is the next action for an invoice. So invoice based on its state, can be

• paid

• approved

• pending approval

• under review

• draft

  etc.

Now each of these state has a logical behavior and a next state. You can have different types of invoices (subclass) that reflects the behavior of each of these state.

The super class(interface/abstract) could have methods like :

needsAction()     : boolean
ownerDepartment() : Department // department it should go to next

Then each subclasses would define own logic for these methods.

This will save your model from being bloated up with too many confusing if-elses and may be worse - switch cases.