Java "workflow" design [closed]

Question

I'd like to ask about designing "workflow merging". I've got several workflows that aren't very similar to each other. However, sometimes I want to combine them modifying them very slightly. Let me give you an example :

Workflow 1 - Trip

A1 (pack the bag) -> A2 (leave the house) -> A3 (catch the bus) -> A4 ...

Workflow 2 - Daily plant watering

B1 (turn the water on) -> B2 (leave the house) -> B3 (water the plants) -> B4 (enter the house) -> B5 (turn the water off)

On Sunday, I want to go for a trip and I need to water the plants too. So I want to create something like A1 -> B1 to B5 -> A2... . I also want to have possibility to tell my friend to finish the watering, which would be something like A1 -> B1 to B2 -> C1 (pass the task to a friend) -> A3 ... As you can see, the flow is straightforward - there are no forks and joins in it and I don't need such functionality. All I need is to create a linear list of commands with possibility to merge them together easily. All fragments of code are Java methods at the moment (and I'd like to make them something like atomic flows).

The main goal of my approach should be avoiding typing the same code over and over again. The flow may have hundreds of steps. I'd like to make a statement like Execute flow A, but instead of running A2 and A3, execute B2 to B6 and continue with A.

I've got two major questions :

• Is there any framework that already supports this? If there is, isn't it too complex for my purpose?
• If not, what would be the best way to implement such thing?

Note : Can you please specify what is so unclear about my question?

Answer 1

I personally feel that the requirement can be implemented without the use of any specific framework. You could design the application as follows :

1. TaskPerformer : An interface with a method named performTask. Represents a Task to be performed.

2. BagPackTask : A concrete class that implements TaskPerformer. Also defines the performTask method that contains code for packing a bag.

3. WaterPlantsTask : Another concrete class that implements TaskPerformer. Also defines the performTask method that contains code for watering plants. Similarly, you have one class per task that implements Taskperformer and defines the behavior for the task using the performTask method.

4. Workflow : A class that will be used for executing two or more tasks and will allow you to mix and match existing tasks. The class will contain a List of TaskPerformer and the constructor for this class will have a List parameter to ask for Tasks to execute. The class will contain an executeWorkflow method that will iterate over the List and call the performTask method of each element in the list. In other words, this class can be used to execute all the tasks passed to its constructor during instantiation by using its executeWorkflow method. It is important to note that the order in which you insert elements in the list is the order in which the tasks will be executed.

Using this approach, you eliminate the need to have any if-else conditions to determine what task to perform. You can reuse your TaskPerformer implementations in how many ever Workflow instances as you wish. You get a super clean design. Let me know if you need any clarifications since I feel that this design should solve your problem. It would be a good idea to clarify all your doubts before accepting any answers :)