When is a class too big? [closed]

Question

I tend to create very large classes that have 30-40 (or more) methods. How many methods are too many? Are there any "smells" or rules of thumb to use?

Answer 1

Step one is to adhere to the Single Responsibility Principle. If you can't say in one sentence what your class does, then it probably does too much.

Once you've narrowed that down, I don't know that the number of methods really matters as long as your methods don't do too much.

Answer 2

I'll bite. Without doing much more than wading into the very shallow edges of the deep waters of O-O design, I'll through a couple of my rules of thumb:

1. Static properties are highly questionable. Question yourself strongly about whether or not they are really needed.

2. Most properties/attributes of a class should be private (accessable only by the object instance) or protected, accessable only by an instance of the class or of a derived class (subclass).

3. If a property/attribute of a class is visible to the general public, it should most likely be read-only. For the most part, the state of an object instance should change only by its responding to a method asking it to do something useful (e.g., you request that a window move itself, rather than explicitly setting is origin on the coordinate plane).

4. Public Getter/Setter methods or properties are questionable as they primarily expose object state (which see item #2 above).

5. Public methods should primarily expose the logical operations (messages) to which an object instance responds. These operations should be atomic (e.g., for the object to be in a logically consistent internal state, it should not depend on an external actors sending it a particular sequence of messages). Object state should change are as result of responding to these messages and should be exposed as a side effect of the message (e.g., a window reporting its location as a side effect of asking it to move is acceptable).

The above should cut down the public interface to your objects considerably.

Finally, if your object has more than a few messages to which it responds, you likely have a candidate for refactoring: is it really one monolithic object, or is it an assembly of discrete objects? "More than a few", of course, is a highly subjective (and contextual) number -- I'll throw out 10-12 as a reasonable limit.

Hope this helps.

There are lots of books out there on O-O design, analysis and modelling.