How many objects are too many?

Question

When designing an application, does there come a point where you have too many objects? How do you determine when you've crossed the line of granularity in your object model?

Answer 1

At the point when you wonder "why the hell is this an object?"

I recently had a "BetForgetter" class which I refactored into 2 lines of code in another class.

Answer 2

I'm not sure what the answer is in the scope of an entire project, but I can usually tell that two classes might be better off as one if they depend too much on each other.

Answer 3

Not only with too many objects but also with too much complexity, I detect the point when I feel lost reading my code after one day off.

Answer 4

I'd say that you should probably worry more about having too few object/classes. SRP is something worth abiding to as it usually leads to cleaner and more readable code.

Answer 5

No hard and fast rule, but pretty much up to the programmers discretion.
But as a general rule of thumb, if your wasting time writing classes to to the tiniest operation, then thats to many....and complex. If your writing megalumps of code then that's too little.

Answer 6

I think that it's impossible to answer your question without knowing your problem.

It depends a lot on the problem that you're trying to solve with your application.

Iraimbilanja is absolutely right. If you start creating objects for everything that crosses your way, you soon will be wondering what is the use that you can give them, and why the hell you're spending time to create them.

Answer 7

This is probably a symptom of another problem.

IMHO-As long as you have good project, namespace, and/or directory organization, along with a reasonable naming convention, you should be able to handle any number of classes easilly.

PS-I'm assuming you meant 'classes' when said 'objects'.

Answer 8

You can never have too many of them, ask any decent Java programmer.

Answer 9

I assume that you're talking about types and not objects (I know it is called an object model, but it really is a model of the types involved).

Anyway, if you subscribe to the Single Responsibility Principle, which states that each type should only handle a single responsibility, the number of types will grow as the application grows.

However, each type should be fairly easy to comprehend due to its limited size, and assuming that you have some kind of structure in place, you should rarely (if ever) need to look at all the types at a time.

Managing large software project is all about splitting things up into manageable pieces and labeling them in a sensible way. If you do that, the number of types becomes less important in my experience.

Answer 10

A project with proper OO design, with hundreds of objects, is in a much better state than one with fewer, monolithic classes.

Answer 11

How long is a piece of string? (twice the length from the middle to the end but thats beside the point)

I think it really depends on what you are writing and how you have written it. The number of objects is a bad meteric, you should be worrying about complexity of your object model not how many objects you have. How tightly coupled are your objects is what you need to be asking.

If you have 100 different type of Bird object all of which implement an interface and the shared methods are in an abstract class then you don't have too many objects because maybe you need each Bird to act differently.

However if you have a mess of obejects that all implement the same code then you have too many objects and can refactor to having less.

Similarly if you have one huge class that contains lots of disparate functionality then you have too few classes.

Unless you have classes that do the same thing or are replicating things that other classes in the framework already do they you are fine.

And remember just because you can use inheritence doesn't mean you have to, composition is often better.