I have a process that I am automating into a kind of GUI step by step wizard. In basic terms it is a long drawn out set of calculations that end up giving you specifications for a design at the end.
It is broken into 6 chunks, and each successive chunk relies on results and inputs from the previous chunk. I originally considered doing 6 separate ‘calculating’ classes until I started thinking about handing the values ‘down the line’ as it were.
I just did a similar task where I slapped a GUI on an already implemented, very similar program, where the previous guy did do it with separate classes and it was quite a pain keeping track of them all and making sure they got handed to the right classes.
I was thinking of combining them all into one big class. It would have 6 methods where I can collect and give the input from each section of the GUI and it would do its calculations behind the scenes, and then after all 6 have been called, I can simply create one output method that collects all the important values and spits them out.
I am leaning towards the one class because it is simpler, more ‘black-box-like’ and I don’t have to have dirty constructors that I hand the previously made object in to the point that the final class gets all 5 previous ones handed to it so it can use the values.
Now that I think of it this one class can be the ‘model’ of a MVC design and be a nice separated class that the Controller and View only access through 7 visible, very straight forward methods.
I also am thinking that it would reduce memory footprint as with 6 separate classes, they would need to exist for the same duration as 1 big one, except with all the internals of Object replicated 6 times.
I am fairly convinced about using the one class, but I wanted to ask if this is a terrible mistake, if it goes against all things obect-oriented and if I’m missing some obvious much better solution.
Some things to consider with putting all the steps into a single stateful class:
1) Will it actually be simpler if you add the code that makes sure it is in a consistent state at all times? Make sure the methods are called in the correct order?
2) Can users go backward? Are you absolutely certain it will never be a requirement to be able to go backward? Does that mean you need another 6 methods for ‘reversing’ steps and checking the state of the object? (ostensibly in the other system you could just “getPrevious” if it’s done right.)
3) Who manages the lifecycle of this object? Who knows when you’re done with it, where is the reference to it kept? In the other system it seems like each screen knows about its own input and its own output. With one object every screen knows about the entire state of the process. Plus the first and last steps will probably have “special knowledge” about the process since they’ll likely have to contain the code to start and end the lifecycle.