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?

  • 3
    Humans seem to have an inbuilt forget range. Once you get past seven options the first few start to be forgotten. So don't give people more than 7 options per interface. Commented Aug 29, 2011 at 16:09
  • +1@Martin- 7 +or- 2
    – user3792
    Commented Aug 29, 2011 at 16:22
  • This limitation is for short-term memory only. Otherwise, how could we possibly remember all those different letters and words? Seriously, if the class is going to be used heavily, you can think of it as mini-language, and have as many methods as you need to express whatever you have to do with it.
    – artem
    Commented Aug 29, 2011 at 23:50
  • possible duplicate of Are There Metrics For Cohesion And Coupling?
    – gnat
    Commented Oct 22, 2015 at 20:59
  • 1

4 Answers 4


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.

  • Correct, but if it is a utility class, upto 10-15 is fine.
    – Sid
    Commented Aug 29, 2011 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.
    – user3792
    Commented Aug 29, 2011 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
    Commented Aug 30, 2011 at 6:27

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


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.

  • 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
    Commented Aug 29, 2011 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. Commented Aug 29, 2011 at 14:17
  • Exactly...probably to make concepts clearer for the most and to enlarge the potential basis of buyers too...
    – Francesco
    Commented Aug 29, 2011 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
    Commented Aug 29, 2011 at 15:03

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.

  • +1 - the 7 +-2 rule is a rule to live by where usability is concerned.
    – user3792
    Commented Aug 29, 2011 at 19:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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