What is the limit to the number of a class methods?

Question

In different design books that I read, sometimes big emphasis is put on the number of methods that a class must have (considering an OO language, as java or C# for instance). Often the examples reported in those books are very neat and simple, but rarely they cover a "serious" or complex case.
However the range seems to be between 5 and 8.

In a project I developed a class "Note", with its attribuse as properties: Title, Desctiption, CreateDate, etc.
Then some basic methods like: getRelations (if the note is assigned to different documents), getExpiryDate, ect.

However proceeding in the development of the application, more functionalities were required, and, therefore, more methods.

I know that the less methods a class has, the more loosly coupled it is. That is indeed a good advantage in terms of modularity and reusability, plus easier to edit.
By the way if in our context there is no need (or even sense) to create sub-classes and all the needed functions are related to that class, how many methods can we further attach?

I agree that having more than 15 methods, then maybe a little re-design might be required.
But even in that case, if deleting some of the methods or inheritance is not an option, which would be the proper way?

Answer 1

Have as many methods as you need. I would try to keep down the number of public methods to that 5-8 rule if possible. Honestly, most people have the opposite problem where they have crazy super-methods that need to be broken out more, not less. It really does not matter how many private helper methods you have. In fact, if you stayed below 8 methods in Java you could hit the limit with a class that only had a constructor, a toString, and the getter/setter for 3 properties...which is not exactly a robust class. The bottom line is, do not worry about how many methods your class is. Worry about making sure your class does not take on unrelated concerns, and that you have a reasonable public interface that has easy to understand methods.

Answer 2

The answer is really simple: Put everything in a class that belongs to its responsibilities, but be careful when assigning responsibilities.

Sometimes a big class is a composite of smaller classes with different responsibilities.

In general, I try to divide the responsibilities into smaller classes when the class becomes unwieldy in its usage or in maintenance. I seldomly have classes that are longer than 500 lines. My biggest classes have approximatelly 1.5k locs.

You simply cannot state a general rule like "a class should have between n and m methods".

Answer 3

There is no reason (in OO design) for having only so many methods. It is also not true that a class with less methods is better decoupled.

Look at the java.lang.String class, for example. Lots of methods, because there are so many things one can do with a string. Nevertheless not coupled strongly.

I wonder why a magic number like 15 could separate good and bad design. No, it's not that easy.

Answer 4

In PMD, the default behavior of the TooManyMethods rule is to identify and flag classes with 10 or more methods as potential errors. This is just an arbitrary number, though. It's easily changed in a configuration. Regardless of what this number is, it's just a flag for a developer to look at a class and see if there is an issue, not that there is a problem with it.

Something that is a little more concrete might be the 7 plus/minus 2 rule. This states that the human mind can hold and comprehend between 5 and 9 "objects" in memory. When reading a particular class, the objects would most likely be the methods and fields that make up that class. However, classes frequently have more than 9 fields and methods, even if you don't count accessors, mutators and any standard operations (for example, toString(), hashCode(), and equals() in Java).

The most relevant measures would be of fan-in and fan-out and discussions of coupling and cohesion. The single responsibility principle and separation of concerns should be applied - a class should do or represent one thing and one thing alone. These are far better than trying to assign numbers to maximum/minimum number of methods when assessing a design or implementation.