dreamingmind
commented
9 years ago - Mediator
- Might be a solution for the handling class that gets delegated to do the final algorithm after we've determined what that is. If the various tool classes that get instantiated by the algorithm class start to become to aware of the needs and processes of each other, writing the algorithm as a mediator could correct the problem. It would allow each tool to have simple calls and results. The mediator would take on the task of deciding the implications of the result and how to proceed based on it.
- This is the right pattern for the fieldset tool extension that manages fieldset save calls when there may or may not be other required or dependent fieldsets on the page.
- Command
- Not to promising.
- Might work if it was only a matter of having multiple buttons to initiate the various exit paths. Each button could be a call to a Controller that pulled together all the needed tools for itself, then executed the process. Not the worst possible solution. But I think a number of variations will fall on a single button, so there will still be a lot of logic sorting things out. And a lot of that logic would be duplicated in different Controllers. For example, every checkout path would need to check to see if the price was valid and billable before starting its work. And they would all have to route to the proper alternate process if the price wasn't valid.
- Chain of responsibility
Composite- Makes tree structures that can be operated on. No.
What design pattern can allow me to manage all these possibilities?
I think the problem is this:
There are going to be several classes involved in carrying out each checkout process. There will be overlapping use of the classes for the various processes, but not an exact match. And each process will follow a different logical process as it uses the classes and their methods.
So having all these checkout procedures in one class is going to involve a ton of conditionals, switches or branches. A big mess.
And to have all this written into the cart system would require any installing system to implement a lot of code that might not be necessary.
What's needed is some way to funnel all checkout paths into one simple class that decides on a class to handle the chosen process. That new class pulls together all the tools it needs for its task and follows the logic to accomplish it.
This way, one or many different checkout strategies might exist but no specific code would be required of the system that used the cart plugin. Each using system could define the processes and supporting code it needed.