This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I'm new to design patterns and therefore I'm not sure which is the best pattern to use for my implementation task.
We are going to develop a workflow system that consists of data and different software tools that process these data. Each tool takes as input some data usually in a certain file format or a kind of list, processes these data and produces as output some result data in another (file) format. The user has to define at the beginning of the workflow process several parameters:
These are - the input data set for the first tool - which tools should run during the whole process - the order of the tools - some tool specific parameters
During the whole process the output data one tool produces are the input data the next tool is using, therefore during each step the output data have to be reformatted in order that they fit to the input format for the next tool. All intermediate result data are stored to a database in order to check and understand later what has happened during the run and to be able to reuse them again for other workflow runs with different orders of tools and different parameters. It should be possible later to add new tools to the whole system.
Which design pattern(s) can be used for that?
Many thanks in advance to all for any kind of help, suggestions and replies.
The GoF design patterns come into play at a lower level than the description you gave. They represent solutions to similar problems found in other systems, so you have to get down to pretty generic problems to find widely reusable patterns.
For example, at some point you're going to have to read an input. You might look in the inbound parameter packet and find a mime type for the input. Then you could look up a Strategy to read that mime type. A data converter might look like:
Of course it would never be quite that simple
Does it make sense to wait until you're desiging some components before looking for opportunities to use patterns?
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Joined: Jan 18, 2006
thank you very much for your reply.
It seems that my question was to general, sorry for that. The whole system will be a web-based application using Struts and Hibernate. There are components for data loading, perisisting the data, viewing the data and something like a workflow component that should be as independent as possible from the other components (thanks for pointing me to the enterprise level patterns).
This is my first approach to apply the GoF patterns and the idea is to look initially to this workflow component. One of several problems here is that this component has to execute different software tools in a variable order. The nature of these tools is considerably variable. Either they are command line tools (written in Perl, C++, C or something else), or it could be a database that has to be queried. In the future new tools will appear whose nature is not yet known, but it should be also possible to integrate them into the system. Therefore it is necessary to mask this variable nature somehow to the system. Is it possible to use for such problem the adapter or the facade?
Until now I tried to find my way through the pattern jungle with the GoF book. But honestly I feel a little bit lost with that, specially when I want to decide which pattern to apply at which level in my system. Just recently I discovered the Head First design pattern book which looks at the first glance really great to me and seems to be the perfect approach to give me the needed understanding. But I've just started to go through. At the same time I wanted already to gather some ideas for my system with the hope to work more goal-oriented on that field.
With best regards, Birgit
Joined: Jan 29, 2003
For that particular detail of your system, I'd read up on Strategy. Each of your strategies might be an Adapter that presents you with a common API but translates your calls into the specific APIs of the particular tools. Or the strategies might just launch the tools with a single Command-like execute() method. See if that much reading makes sense.
As Stan hinted, the command pattern makes sense to this problem. A Command object basically encapsulates an action on a receiver. This decouples the object making the request from the object receiving and executing the request through the command object. You can set different command objects dynamically in the invoker and thus execute different actions on different receivers. You can add new receivers by adding new command objects for them without changing the invoker's code. Here the receivers are your tools and the invoker is your workflow system. If this makes sense to you, read up on the command pattern from HF design patterns. Its explained beautifully with a lovely example.
Joined: Jan 18, 2006
thanks a lot for your suggestions. They give me really a good starting point for my work.
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com