24

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?

Francesco
  • 547
  • 1
  • 4
  • 12

4 Answers4

30

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.

Morgan Herlocker
  • 12,742
  • Correct, but if it is a utility class, upto 10-15 is fine. – Sid Aug 29 '11 at 19:11
  • 1
    @SidCool - I'm not saying I do not use them ever, but utility classes are not really a best practice to begin with. They are typically just a mini god class that put a bunch of unrelated concerns together. With that in mind, a utility class really should not exist at all, much less with 15 methods. – Morgan Herlocker Aug 29 '11 at 19:27
  • 1
    My class "Note" is not a utility class. It represents a business object (a note that can add comments and description to a document). However I agree with ironcode about the danger of "utility" classes. They come in help when we are in hurry with our delivery deadlines, but I think there is often a better solution/design for them. – Francesco Aug 30 '11 at 06:27
13

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".

Falcon
  • 19,308
8

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.

Ingo
  • 3,921
  • I agree, the number of 15 was just an approximation derived from reading those designing books (as "Code Complete" by Steven McConnell, as example). Indeed String class has a miriad of methods and all realted to the same entity. – Francesco Aug 29 '11 at 14:11
  • @Luca: The problem with some of those books is that the examples are often contrived and therefore smaller than many real-world examples. – FrustratedWithFormsDesigner Aug 29 '11 at 14:17
  • Exactly...probably to make concepts clearer for the most and to enlarge the potential basis of buyers too... – Francesco Aug 29 '11 at 14:28
  • I wanna see any kind of DataGrid or even UI control with only 15 methods. If you broke those classes down into smaller ones then the interface would become a nightmare. – Falcon Aug 29 '11 at 15:03
7

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.

Thomas Owens
  • 82,739