I am developing a software for a laboratory to test some devices. To test each device there are multi subtests which should be done to reach to the final result.To perform a complete test, the software must pass Stage1 then automatically goes to Stage2 then Stage3 and so on until the whole test is finished. meanwhile the user can select to just have the Stage3 or Stage2 or any other Stages independently to be performed (which she selects that at runtime).
this is the thing I have done so far:
public class IronTestWorkFlow:ITestWorkFlow
{
private readonly List<ITestStages> _testStageses;
public IronTestWorkFlow(List<ITestStages> testStageses )
{
if (testStageses == null)
{
throw new ArgumentNullException("testStageses");
}
_testStageses = testStageses;
}
}
I am useing a DI container. But I don’t know how to change the list of Stages in ITestWorkFlow at runtime.
Questions:
1- Am I designing this right?
2- If yes which pattern shall I follow to obey the principles and change the stages at runtime? and how can I do that?
Things are Bass-Akwards
The technical term for this is inversion of control.
Your IronTestWorkFlow constructor:
public IronTestWorkFlow(List<ITestStages> testStageses )
How did you know what stages to build before you knew what kind of Workflow you were building? You don’t, which is why you’re in this quandary I think. Premature injectulation.
Factory Pattern instead of DI Container
Let’s use the Factory Pattern – put the Workflow and Stage building into WorkflowFactory and StageFactory classes respectively. The user will select an iron test for example so the IronTestWorkFlowFactory is called which in turn calls the StageFactory to build the stages it needs. Thus we have the context needed to build the right stages.
I take it from the problem description that higher level code should be able to call on a WorkFlowFactory or a StageFactory as desired, depending on how granular or customized of a thing the user wants. So make sure any dependencies between the factories is done via parameters; that’s basic Dependency Injection. A DI container is not necessarily required to do dependency injection.
Stay object oriented
Think long and hard about the things you’re manipulating: Stage, WorkFlow, other? Focus on the core “data structures” first.
Beware too much focus on high level abstract “framework” without some meat designed into core classes, which results in these classes badly un-encapsulated with numerous violations of single responsibility principle further resulting in undesirable and painful coupling.
For example I wonder what a Workflow – an ordered list of stages – looks like and what fundamental operations are done with them. I wonder if there is some business rules that define order independent of the order in which they just happen to be instantiated? If so then implementing IComparable can make a profound difference. Been there, done that.
This problem doesn’t necessarily need to be solved with design patterns but, to answer your question, you could arrange the tests you need using a simple list or use a composite pattern if you want to make a little more complicated. You could then use different strategies to iterate over the list of tests, each strategy reacting to success or failure appropriately.
This might not be your final solution, but it’s food for thought…
2
You can use a Mediator pattern. You would have a master list of all available tests in the master workflow. A user won’t talk to this workflow directly, but instead to the Mediator. The Mediator will keep track of which tasks are actually selected (in its own list), and expose those to the user.
1
It would appear there are a myriad of patterns that may be employed here. One to consider is the State pattern if you must transition from one test to another automatically (each State must know how to transition its context to the next state, in your case, these states would be your specific lab tests if I understood the problem correctly)
or even some variant of Chain of Responsibility might be useful.