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?
Best Answer
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.