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?

  • 2
    Swing is notorious for class proliferation. Though to be fair, UI's tend to be like this in general. Dec 3 '15 at 16:57
  • 1
    On a linguistic note, too much is never too many. Too much may be too much, and too many may be too many. Dec 3 '15 at 17:33
  • 2
    The question is: Are the classes well designed with low coupling and high cohesion? Then you have the appropriate number of classes. If a good design for your task requires a high number of classes, then so be it. An absolute number like 22 classes does not tell you anything either way. You have to look at the individual classes to see if some are superfluous or some are "god-classes".
    – JacquesB
    Dec 4 '15 at 10:24

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

  • If you have a relatively 50/50 interfaces to implementers ratio then you have bad abstractions or not good enough design. Or, too much design; it's over-engineered.
    – radarbob
    Dec 5 '15 at 21:42
  • Everything crammed into the main class I see many (many) classes that have the functionality they need but it is spewed out "at that level" and the class is "crammed" with code. If they had just made appropriate classes for given functionality! "maximize cohesion" => "single responsibility principle" => tends to more but smaller classes, simpler classes; and it is a real "a-ha" moment to see that simplicity maintained through the composition layers. Sadly, they quit designing when they get inside of a class. To them I'd like to say design principles are fractal.
    – radarbob
    Dec 5 '15 at 22:17

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.


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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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