Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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: enter image description here

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?

share|improve this question

migrated from stackoverflow.com Jun 14 '13 at 11:34

This question came from our site for professional and enthusiast programmers.

4 Answers 4

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.

share|improve this answer

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...

share|improve this answer
    
Thanks for your answer but how can I change the list of Stages at runtime? shall I use Property Injection or something like that? –  Mehrdad Kamelzadeh Jun 14 '13 at 9:19
    
The strategy would iterate over the tests so you could construct a new strategy each time with a different set of tests injected into the constructor. Property injection would also work. It may be worth injecting the list of tests into the strategy's main method. This way you can keep the same strategy instance and run it against different lists of tests. –  David Osborne Jun 14 '13 at 10:12

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.

share|improve this answer
    
Not sure this is really Mediator, but it's a good suggestion anyway. –  Amy Blankenship Jun 15 '13 at 20:32

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.