|laziness, impatience, and hubris|
Decision Trees and the Strategy Design Patternby djantzen (Priest)
|on Dec 26, 2002 at 01:24 UTC||Need Help??|
Hi All, I am currently working out the object model for what is basically a ticket tracking system. The idea is to facilitate discussion between authors, editors and supervisors regarding documents. We have the tools already in place to create the documents and even different versions of documents, but what I'm developing now is a flexible object model to express a decision tree in such a way that if the policies of the group change down the road, altering the system to reflect the new procedures is as painless as swapping out a single module. This leads me to consider the Strategy design pattern.
Here's an example decision tree:
Now it seems to me that I just need a single object to encapsulate where in the system a given document is, and what its status is. But I want the interface for this thing to be simple, so to the user it just seems like an object moving along a track. Something like:
The hard part is that I want to be able to describe the decision tree, or track of possibilities, in a module that can be swapped at will. So I've got an idea to do something like:
Right now I'm thinking about having each Ticket object contain a reference to a Track object, although this could be implemented as class methods in Track as well. I'm not strongly attached to either approach, although the latter would make this more of a classic Model-View-Controller arrangement than an application of Strategy. Anyhow, in the event of a policy change, a subclass of BasicTrack, or an entirely new subclass of Track could be implemented, without altering the other components.
Is this sensible or nuts? Shortcomings and pitfalls? Many thanks in advance! fever