At the moment we have just the one class DARCDesign and we are relying on using that for all our design space needs (ie delayed, delayed magnitude effect, risky, delayed and risky). In a way this is good because we just have a single class and call it with our desired options. But it's not so good in that:
it's making demands on the user in terms of calling DARCDesign with the right magical set of arguments.
it's leading to a lot of logic and conditional execution depending on whether we are dealing with delay magnitude effects (multiple RB values) or not.
Solutions ideas:
use alternate constructors which allow you to make simple calls and it does the hard work of selecting the arguments. Although this does not solve Problem 2 above.
use separate sub-classes (or using inheritance) to deal with different design type situations
WAIT UNTIL #32 IS RESOLVED THEN REVISIT THIS (EDIT: no, do it).
[x] add alternate constructors (as class methods)
[x] use these in chooser.py
[x] add to tests
We now have some alternate constructors, so it is easy to ask for BAD design generators using delayed or risky and delayed and risky designs etc. It just means you don't have to specify all the design variables manually and it uses the defaults set in these alternate constructors.
At the moment we have just the one class
DARCDesignand we are relying on using that for all our design space needs (ie delayed, delayed magnitude effect, risky, delayed and risky). In a way this is good because we just have a single class and call it with our desired options. But it's not so good in that:DARCDesignwith the right magical set of arguments.RBvalues) or not.Solutions ideas:
WAIT UNTIL #32 IS RESOLVED THEN REVISIT THIS (EDIT: no, do it).
chooser.pyWe now have some alternate constructors, so it is easy to ask for BAD design generators using delayed or risky and delayed and risky designs etc. It just means you don't have to specify all the design variables manually and it uses the defaults set in these alternate constructors.