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, 2015 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, 2015 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, 2015 at 10:24

5 Answers 5


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.

  • 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, 2015 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, 2015 at 22:17
  • @radarbob: Are we counting mocks as implementers? Because if not, having a 1:1 of interface/implementation (barring DTOs) is perfectly fine. I'm also sensing that this metric is negatively impacted when nested interfaces exist for valid reasons; thus shifting the ratio towards interfaces yet not necessarily being a case of overengineering.
    – Flater
    Feb 1, 2022 at 14:09
  • "interface/implementation ratio" is not a term I've ever used when describing excellent OO design. When designing the problem domain good classes implement functionality and hide state through its public members - the class' interface. Derived requirements, unit testing considerations being one, influence design certainly, but do not supersede that OO precept. When done implementing if one has leftover sets of method definitions, that other interface kind, then at the very least I suspect the "D" in SOLID is being violated.
    – radarbob
    Feb 14, 2022 at 23:27

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


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.


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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