Disadvantages of the chain of responsibility [GoF]

Question

We need to build a solution for processing sales orders. Processing is carried out one at a time: each step takes care of specific tasks: check if the client has credit, check if the required item is in stock, etc.

We thought about using a chain of responsibility chains.

I found this old but very valuable article . It starts by comparing CoR with a template template. Since we are not interested in communication, they both work.

Are there any flaws (or traps, etc.) that I should be aware of?

Answer 1

This is not very suitable: the Chain of Responsibility template is the delegation of tasks that the earlier steps cannot complete.

In your case, you want each step applied, so CoR is not applied.

What you really want here is a kind of business process engine like jBPM . Processors are designed to work in this form and provide many functions that are difficult to implement in a manual solution, for example:

• The ability to have lengthy processes that are stored in the database. It's not funny trying to debug an order that gets lost because you need to restart the server ....
• The ability to wait for external events in message queues (for example, to receive confirmation from a remote system). It may not be necessary in some simple cases, but it becomes essential if you integrate with external providers.
• Exceptional processing and rollback / process compensation
• Event Logging and Reporting

In principle, this is one of those situations in which I would advise not to reinvent the wheel .....

Answer 2

I can no longer agree with mikera.

1) COR does not fit - Why? In addition to what mikera said, your definition of the problem speaks of structure. You have a sequence of operations (credit check, inventory check, etc.), but you have chosen the “Chain of Responsibility”, which is a behavioral pattern. I feel something is wrong.

2) Do not reinvent the wheel - especially if you are talking about financial instruments, such as sales processing.

However, in a completely different note, you can use the Facade design pattern to represent a unified interface that encapsulates subsystems. The example here has the same business example as your problem.