How many classes are too many?

Question

I'm making a Book Manager App using Java Swing that allows me to do a variety of things such as opening a txt list of books, searching for books, adding/removing books.

There are different classes for the different types of books e.g. Fictional Books have their own genre field and history books have their own period field. All of these books extend an abstract book class which holds the base fields for these classes.

I'm using the MVC pattern and I'm happy enough with the model but my main concern lies with the view.

I currently have 22 classes with 14 of them focused on the View aspect of the model. I basically have classes for the majority of the components. Such as a file chooser which extends JFileChooser, a MenuBar class and classes for the different book panels. Each Sub book panel extends from a general book Panel by taking all of its textfields and labels and appending their own.

I've also implemented the Builder design pattern that lets me create a range of components so far a I have 2 builder classes both implementing an interface one for textfields and one for labels.

My question is, is all of this a little over the top? Is it better to have everything crammed into the main class or is it better to have a lot of classes?

Answer 1

You question is three-fold:

1. How many classes are too many?

While there are some guides on some metrics like how long should a method be or how many parameters can a method have, there are no such metrics as to how many classes should a system have as a maximum.

IMHO it's not so much the amount of classes that create complexity as it is the fact of their not being cohesive and their being strongly coupled to each other. If the classes are too big, there's a problem and there are metrics for that. If the classes are tightly coupled there's another problem.

In the other hand, how many abstract classes or interfaces, while not being a direct indicator of complexity, it can give you a hint. There should be a relatively high ratio of implementing classes to interfaces. That mean that your abstractions are good and are serving a good purpose. If you have a relatively 50/50 interfaces to implementers ratio then you have bad abstractions or not good enough design. The latter doesn't apply at the early stages of development since there will obviously be roughly the same amount of interfaces than that of implementors.

2. Is all of this (all my classes) a little over the top?

See previous question. But also ask yourself whether you (your team) feel overworked of overwhelmed by the amount of things to take care of. In that case help should be asked. Splitting work between presentation-layer programmers and business rule programmers could help.

3. Is it better to have everything crammed into the main class or is it better to have a lot of classes?

You are answering yourself here by using the word "crammed". That's a known anti-pattern called God-class. You should avoid it.

Bottomline: it's not the amount of components but the relationships between them what make a system too complex to maintain.

Don't look at the amount of classes. Make an UML diagram leaving out all leaf classes. Does it look clean and simple, or at least manageable? If it does, then you are OK.

Answer 2

You're asking the wrong question. It's not "better to have everything crammed into the main class", nor is it "better to have a lot of classes".

When we distance ourselves from such attempts at generating rigid rules to cover all cases, we arrive at a much better approach: abide by widely-accepted design principles, such as those embodied by SOLID, and we will end up with an appropriate number of classes for your codebase.

Whatever that number is.

For GUIs in particular you will tend to end up with a lot of classes as you add more widgets; this is normal. The scenario you describe does not sound frightening to me.

Answer 3

The main reason to have classes in any code is to make that code easier to follow. If you feel that by adding classes, the code becomes clearer and more descriptive and conceptually meaningful...then you're on the right track. But if you feel that by adding classes, the code becomes more muddled, sprawling, or obtuse...then don't do it.

There is no simple formula; every application is different. Only a human can make judgment calls like these. Otherwise computer programs could write themselves. :)

Answer 4

Too many classes is a matter of how many you need to know about to do basic things in your app. This generally has more to do with picking proper levels of abstraction, than strict number of classes. For example, if you need to add a sci-fi genre, the expectation would be making another child class and likely another view class. If it takes more than that, that could be a sign you have a poor abstraction/too many classes. As a general rule of thumb, if you have to create/alter more than one class per requirement then something is probably wrong.

Answer 5

If you have two classes that would be easier to maintain if they were one, then you have too many. If you have one class that would be easier to maintain if it was two, then you don’t have enough.

If you have similar classes that could be just parametrised and become one, that is likely too many. You don’t want a red button, green button, blue button and yellow button class - you want a button class with a Color property.

On the other hand, if you have one class with more and more things added to it, at some point it becomes to unwieldy and could do with splitting up. You decide where that point is.

And there are programming styles that encourage lots of small classes. Whether it’s good or bad depends on the circumstances.