How Many Objects Inside of a Class is too Many?

Question

I'm fairly new to the concepts of OO programming - actually programming in general as I am still a student. I'm currently working as an intern in a department that has me coding a new structure that will probably be the base for all their applications to come. So I believe I have the idea behind OO down where you create "basic building blocks" and then expand, expand and expand, until you arrive at the most complex object (for the time being).

I need to put all these "advanced" objects into one but how many is too many? Can I have 100 objects inside of this bigger object if it requires all these "parts".

I really hope this question makes sense to everyone. I'm sure the answer is not going to be a definite answer either but I just need a rule of thumb to go by. I'd really hate to have 100 objects inside of 1 big one if there is a better design/programming technique.

Thank you.

EDIT 1: Thank you so much for your responses but I'm still a little unclear. I already marked an answer as I felt I can continue with what I have but...

Let me continue with my Human Example. A human is composed of many parts (or objects) and each part is also made up of parts, all the way down to a single cell.

Human --> Arm --> Hand --> Fingers --> Thumb --> Bones --> Bone Cells

Human: ojbLeft_Arm, objRight_Arm, objLeftLeg, objRightLeg, objBrain, objHeart, objLeft_Eye, objRight_Eye.... get my point? How many objects inside the human object are too many? Obviously this Human object is going to be considered massive since a Human is very complex. Do you break down the Arm and Leg objects into objLimbs which then stores them?

I guess as another question: if you don't want many objects, HOW do you avoid them?

Answer 1

100 objects inside a single object isn't strictly inappropriate, but it's definitely indicative that there might be a better way to do it. Consider grouping similar objects into composite objects where functionality is similar for usage in your final "superobject". As a rule of thumb, the number of objects you refer to in a class is a (rough) estimate of the complexity of that object; 100 would indicate a complexity that's too high. Note that you can reduce the effective complexity by grouping objects together into composite objects, thereby increasing your overall object count but reducing your direct reference count within your "superobject".

Edit in response to OP's edit and question: The key to the grouping is really all about your expected usage and your problem domain. Consider your Human example; the appropriate breakdown of the object model is really dependent upon the usage your data model is going to be put to. The key here is recognizing that you're NOT trying to represent all possible objects or underlying reality; you're creating a representation that's appropriate to your expected usage. For example, if you were modeling a Human for a cardiologist, it might be appropriate to have a Human object, under which you would have a Heart object, a Circulatory System object, etc.; under the Heart object you might have Left Ventricle, Right Ventricle, etc.. However, for a dentist, your model would still have a Human at the top, but that Human would likely have a Teeth collection at the next level; the Teeth might include objects for Canines, Incisors, etc.

The key point here is that the underlying object (Human) is the same; the representation is completely different. Your cardiologist doesn't care (much) about your teeth, and your dentist doesn't care similarly about your ventricles of your heart. Usage defines representation. So for your case, you have to determine exactly what your usage is, and that usage can (hopefully) define a clear path to your representation.

Answer 2

There's a limit to what a programmer can remember.

The reason why shouldn't have 100s of members in a class is it just too difficult to maintain.
No single programmer will be able to remember ALL of the members, and stuff will start to get neglected.
You should try to separate the members into smaller logical groups, and store those as members.

Steve McConnell addresses this issue in the book "Code Complete, Second Edition"

Be critical of classes that contain more than about seven data members The number "7±2" has been found to be a number of discrete items a person can remember while performing other tasks (Miller 1956). If a class contains more than about seven data members, consider whether the class should be decomposed into multiple smaller classes (Riel 1996). You might err more toward the high end of 7±2 if the data members are primitive data types like integers and strings, more toward the lower end of 7±2 if the data members are complex objects.