Many people instinctively try to implement a interface or concept as a single class. However, sometimes the implementation is too complicated to be understood quickly and the class size gets too large. If you think this might be the case, take a look at the class variables. If the number of variables is large, if some of the variables could be "grouped" together, or if some of the variables are only used some of the time, try and split the implementation details into their own classes and allow the original class to delegate to or compose them.
Every time you are creating or adding to a class ask yourself if this could better explained in a separate class. This will help you or a co-developer later find what it is they are looking for faster.
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=ad345400-c818-41de-a052-52bad7b5ebaa)
Posts
Smaller classes are usually better, yes. However, I have a caveat and a related point to make.
ReplyDeleteIf a class has a common purpose, and reusability is important, then it may be desirable to include lots of methods for the different common uses of that class. An example of this is java.lang.String. Even so, it is still important to keep the purpose of the class firmly in mind, and not to let it deviate too far from the original purpose. I particularly like your comment on the number of variables.
A related point is on method sizes. These should never get too large. In Java, the lack of closures and syntactic overhead of try/catch can make methods take up a lot of space, but the number of lines with some functional purpose should never get too large. This may necessitate creating more methods (making a class larger), but when doing OOP then this usually means the need for a new class. If that class is to be a subclass, then your overall class may start getting bigger than you want, but at least the size is encapsulated in some way.
My point is that your rule is a good one, but there are other rules to consider, and sometimes there may need to be a tradeoff. Ideally though, classes are small and methods are small. If either get too large, then consider creating new classes.
The java.lang.String is a good example. Although the interface is large, much of the functionality is delegated to other classes (particularly in newer methods).
ReplyDeleteFor example, the String class has a number of methods that operate on a regex string, but this functionality is delegated to a regex specific class. I would go further and say that the older String methods should also be moved to other classes, leaving the String class only as a delegating class. This would keep the class small and act more as a interface declaration.
It is unfortunate that Java requires all methods of the same class to be in the same source file. Although this makes it easier to find the implementation, it is harder to make functions conveniently available, while keeping the classes small.