28 Dec '04 - + 21 - 23 Looking for a Design Pattern
I'm writing some code that does a few different mathematical
calculations, then returns a value. All the calculations use the
same inputs, so there's the potential for a lot of reuse here.
So, I'm looking for the pattern that fits what I need. The
Command Pattern
seems very close to what I want, except execute() doesn't return a
value. In fact, this
description
of the Command Pattern uses it to implement a calculator, but it just
prints the results to the console instead of returning the value.
In order for me to use the Command Pattern, I'd have to change the
interface of the Command interface
either to add a getter for the value or add a return type for the
execute method.
So, I need something almost, but not quite, exactly like the Command
Pattern. How have people implemented this in the past? I
feel there
has to be another pattern out there for this, because it seems so common.
six comments, already:
What you’re looking for is the Strategy design pattern. Basically you have several solutions to the same problem and you encode each solution in a implementation class which extends or implements some superclass/interface.
From there you have options. You can build a factory which chooses the implementation based on some criteria or you can just have a wrapper/proxy which takes the implementation class as an argument and instatiates and invokes the solution class and returns the result.
I’m sure you can find better explanations than this via google. Good luck!
Jason
Jason Jones (email) (link) - 28 December '04 - 10:32
Thanks, Jason. I’ll look into that.
Lance Finney (link) - 28 December '04 - 10:33
don’t get hung up on the interfaces of the pattern. make the interface anything you want. Command and Strategy are very similar. Commands usually encapsulate very different processes with a common interface (usually an execute method of some sort). Strategies are expected to do somewhat more similar things, like implementing different algorithms to do the same thing. Strategies can have multiple methods in their common iterface. It’s just a collection of methods to do something in a certain way.
john f (email) (link) - 28 December '04 - 12:00
A switch statement?
Never use a truck load of design patterns where a bent coat hanger will do.
Tom Hawtin (email) (link) - 28 December '04 - 15:41
I’ve gone with a Strategy pattern here, except it doesn’t quite fit the definition perfectly. The Strategy pattern seems to be intended for doing the same thing in different ways (like adding various Borders to a component). However, in this case, I’m trying to do multiple similar things to come up with 11 different calculated values. Syntactically, Strategy works, but not semantically.
My implementation ended up being what I would have done anyway, but I have a better understanding of how to describe it.
And while a switch statement would have worked for a couple simple calculations, these are 11 complicated calculations. A switch statement would have smelled way too much.
Lance Finney (link) - 28 December '04 - 15:52
I just was checking out your blog Lance and I could not help but weigh in on the stategy pattern solution. I just finished this same solution for an app that had a different number of formulas for the same problem. The strategy pattern is the appropriate solution.
And the comment about coat hangars interesting, but I don’t think the guy that invented coat hangars is coding in Java. Coding to interfaces is rarely a bad thing or so Rod Johnson says…
Adam Waldal (email) - 16 January '05 - 20:35
