9

This question already has an answer here:

When I have an Object that has lots of fields is it better to have them all as fields or try to find logical groupings as their own Objects and make those the fields?

I guess it comes down to which is the greater evil, too many Objects or too many fields in an Object.

Less Objects, more fields:

public class LotsOfFields Object {

    private Foo foo;
    private Bar bar;
    private Baz baz;
    private Dog dog;
    private Cat cat;
    private Goat goat;

    // Getters and setters...

}

More Objects, less fields:

public class LessFields Object {

    private ClicheMetaSyntacticVariables vars;
    private Animals animals;

    // Getters and setters...

}

public class ClicheMetaSyntacticVariables {

    private Foo foo;
    private Bar bar;
    private Baz baz;

    // Getters and setters...

}

public class Animals {

    private Dog dog;
    private Cat cat;
    private Goat goat;

    // Getters and setters...

}

As an aside, if the "more Objects" approach is better, is it better to have the classes as members of the original class (assuming they'd never be used elsewhere) or does that defeat the purpose of not cluttering an Object?

Edit to defend my question not being a duplicate: This is about a more specific issue than "what is the purpose of a class" and to me that alone is enough. To go on, I am really talking more about what makes a more readable/usable class, I'll take the blame for not specifying that though.

marked as duplicate by gnat, user53019, durron597, user22815, user40980 Aug 29 '15 at 1:46

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 1
    @gnat How is this a possible duplicate? – Captain Man Aug 26 '15 at 19:22
  • 3
    Selected answer in the suggested duplicate addresses this question at a broader level. Your question boils down to "what is the responsibility of the containing class and what is the responsibility of the component classes." And without a more concrete example beyond this abstract example, I don't see how you would get a more direct application of the SRP to this example. – user53019 Aug 26 '15 at 19:25
  • A class should have as many fields as it needs. No more, no less. – Pete Becker Aug 26 '15 at 21:49
  • 1
    Animals seems like a misnamed class. It implies the class will simply have data. An object should be data plus behaviors. Consider Zoo instead. – corsiKa Aug 26 '15 at 22:40
18

I guess it comes down to which is the greater evil, too many Objects or too many fields in an Object.

It depends.

The greater evil is having classes do too many things or too many classes for one thing.

In your example, it looks like you have three distinct groupings that have nothing to do with each other. So those shouldn't be the same class. But if all were very related and interact, then there is less problem having them in the same class.

And each example will be different. There's no universal "do this in every case" policy.

Basically, good design should drive which members go in each class. You shouldn't be designing your classes based around making sure you have an arbitrary max of 5 objects/class, for example.

5

The important figure is complexity, not pure object/member count. You can have a simple class with roughly up to 20 members (that's already really smelly, though), and you can have a much too complex class with only five.

Anyway, just grouping members by type won't help. The questions are: Which members have to work together? And, which sub-services can they provide? These questions are important, because you want your small objects to provide good abstractions that actually simplify things in the class that binds them together, not just containers for your data members.

(foo.bar.baz is a codesmell in and of itself!)

2

Ask yourself this, if you separate out the members into separate classes, are the classes doing any meaningful independent work? If the classes are co-dependent, and can do nothing without access to the other members then its probably a bad idea to separate them out.

On the other hand, if one class can meaningfully lessen the workload of the other class or be used independently from the other class then you might consider separating them.

0

As always, it depends. I don't see why would it be wrong. I had classes with as many fields, maybe even more, in a project which scrapped data from a website, so one page was one object (lots of data + some calculated values to speed up things across multiple runs). They were perfectly related to each other.

If fields contained in one class have little to do with each other, it may be a sign of bad design.

It's a red flag, certainly, but a red flag never killed anybody by itself, right? If it makes sense, go for it.

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