Is a single class simpler and better than 6?

Question

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.

Answer 1

I am leaning towards the one class because it is simpler, more 'black-box-like'

I disagree. The idea behind a black box is that the outside world doesn't need to know implementation details -- programming becomes much easier, code more readable, and bugs more isolated, when components are defined only by their inputs and outputs. Here is the joy of interface driven design.

Having "one big class", however well-defined the inputs and outputs are, is actually antithetical to black-box programming and to Java itself. The entire model will have to be micro-managed, when logical sub-components should be managing themselves. (See @csturtz comment about SRP!).

I also am thinking that it would reduce memory footprint as with 6 separate classes

Seriously? Don't worry about this. The memory footprint of six model classes will be negligable when compared with Swing or the JVM. If memory is actually a serious issue, make this a command-line program. Don't sacrifice potential OO purity for a phantom performance concern; Java was built so that you could write expressive OO code, and have the JRE run it very efficiently.

---

It appears you are implementing a pipeline design, where input is processed in steps. What are the benefits of representing stages with classes?

• Extract shared functionality and data into an abstract class or interface, and you will avoid repeating yourself.
• Six is an arbitrary number. What if more stages are added or some removed? With a class you have a kind of prototype: instantiate as many as you need, and manage them in the same way.

What about the stages in a pipeline could you extract into an interface or abstract class?

• Text describing what this stage does
• The input received
• The process of calculating output
• The set of algorithms used for calculation (see strategy pattern)
• Signaling that calculation is complete
• The ability to cancel progress
• The calculated output
• The ability to recalculate

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

Hopefully we cleared this up.

Answer 2

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.

Answer 3

I think splitting things up in 6 seperate files and classes makes no sense, I agree.

My suggestion is to go for inner classes. As far as I know, it's a quite common practice in Swing programming. Pros:

• can be combined in one source file
• They can be nicely documented
• have access to all member variables in the surrounding class

Don't miss the advantages of OOP:

• can extend other classes (for instance Thread for long running calculations)
• can implement interfaces (for instance can be registered as ActionListener (Swing) or SelectionListener (SWT).

Since inner classes can be made private, black box model would be fully accomplished.

Answer 4

Another alternative is to create 6 classes, each implementing a common interface, call the interface Stage. A Stage would have nice hooks to feed from/to other Stages. This modular approach could make the code more readable and changeable for the next guy.

Answer 5

I doubt there is one simple answer to your question. Whether to split the code into 6 classes or combine into 1 class would depend on several criteria, including how different (functionally) these 6 calculations are, how related the input-output values are, etc.

Provided these 6 pieces are 6 individual steps in computing one common goal - and they only really make sense together (that is one of them cannot be called from elsewhere with some reasonable sense) - I would go for a 1 class approach. Especially if the 6 different sets of calculations use similar/related algorithms and intermediate values/functions/etc. It is in essence the model in the MVC world.

Answer 6

As long as the code is broken down into different methods and you can keep the cyclomatic complexity down, I see no downsides, with a lot of potential for upsides if using only a single class, especially in terms of memory footprint.