Is a low number of members in a class considered a code smell?

Question

I am currently making a simple to-do list program using the MVC pattern, and thus have a model class for the Notebook. However, something feels "off" as it has a very low number of members.

The Notebook is composed of categories, which are composed of To-do lists, which are composed of Items.

What I cannot place is whether this is a case poor analysis (e.g. there are more members and responsibilities I am just missing them..) or perhaps a code smell that the class is not needed (in that case I'm not sure what to do as I could just have a list of categories in that controller, but then I don't have a notebook entity modelled which seems wrong as well).

Below is the very simple class I have:

class Notebook
{
    private String title;
    private List<Category> categories;

    public Notebook(String title, List<Category> categories)
    {
    }

    public void setCategories(List<Category> categories)
    {
    }

    public List<Category> getCategories()
    {
    }
}

I often have this issue where it feels like I am making classes for the sake of it and they have a very number of members/responsibilities, so it would be nice to know whether I am stressing for no reason or not.

As a general rule of thumb, the fewer member variables the better! There is a school of thought that all objects fall into one of two categories: those that manage the lifetime of a single value, and those that manage the interaction of two values. Following this principle to the extreme would result in objects that never had more than 2 member variables. — MattDavey, Jun 27 '13 at 17:29

score 1 · Accepted Answer · edited Jul 11 '13 at 14:04

Not necessarily, there is the concept in Domain Driven Design of what is called a "Standard Type". Which is really a basic primitive wrapped in an object class. The idea is that the primitive contains no information about what information it contains, it's just a string/int/whatever. So by having say an object that surrounds the primitive and ensures that it is always valid ensures that the object has a meaning far beyond just the primitive it contains e.g. a Name is not just a string, it's a Name.

Here's an example taken from the comments of Velocity

public class Velocity
{
    private readonly decimal _velocityInKPH;

    public static Velocity VelocityFromMPH(decimal mph)
    {
       return new Velocity(toKph(mph));
    }

    private Velocity(decimal kph)
    {
       this._velocityInKPH = kph;
    }

    public decimal Kph
    {
       get{ return this._velocityInKPH; }
    }

    public decimal Mph
    {
       get{ return toMph(this._velocityInKPH); }
    }

    // equals addition subtraction operators etc.

    private static decimal ToMph(decimal kph){ // conversion code }
    private static decimal ToKph(decimal mph){ // conversion code }
}

+1 [object calisthenics](https://www.google.co.uk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CC8QFjAA&url=http%3A%2F%2Fwww.xpteam.com%2Fjeff%2Fwritings%2Fobjectcalisthenics.rtf&ei=pnbMUZioMaPQ7AbxhoHIDw&usg=AFQjCNFNSHFqJKUMFLkjtH9QKMQILPfGaA&sig2=jSy99GkMi1sRQ1UId_djmA&bvm=bv.48340889,bs.1,d.d2k) does a great job of explaining this concept in Rule3: Wrap all primitives and strings. — MattDavey, Jun 27 '13 at 17:31
+1 more. Strong types prevent mistakes where you try to use two incompatible values that share a common primitive type. For example, if you have "int rowsPerScreen;" and "int milesPerHour;", a statement like "distance = rowsPerScreen * milesPerHour;" is syntactically and mathematically valid, but semantically meaningless. If you had strongly typed them as "ScreenRows rowsPerScreen;" and "Velocity milesPerHour;" you could never make that mistake. — John Deters, Jul 10 '13 at 20:48

Is a low number of members in a class considered a code smell?

1 Answers1