|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Page 5 of 5
A set of well-named, functionally cohesive methods serves as an outline for someone trying to understand a class. It gives a good overview of what a given object does and how it should be used. You should try to declare one method for each conceptual activity your object can perform, and give each method a name that describes the activity as specifically as possible.
Cohesion is not a precise measurement. It is a subjective judgment. Likewise, the process of deciding whether a particular piece of data is used for control or whether a particular class has too many methods is subjective. The point of these guidelines is not to define a precise measure for good method design, but to suggest a mental approach to take when designing methods. This approach can help you create code that is more flexible and more easily understood. As with all guidelines, however, they are not laws. When you design methods, ultimately you should do whatever you think will best communicate to your programming peers what the method does .
The gist of this article can be summarized in these guidelines:
The maximize-cohesion mantra
Always strive to maximize the cohesion of methods: Focus each method on one conceptual task, and give it a name that clearly
indicates the nature of that task.
The watch-what's-going-down guideline
Avoid passing data used for control (for deciding how to perform the method's job) down into methods.
The method-explosion-aversion principle
Balance maximizing method cohesion (which can increase the number of methods in a class) with keeping the number of methods
in a class to a manageable level.
The golden rule
When designing and coding, do unto other programmers (who will be maintaining your code) as you would have them do unto you
(if you were to maintain their code).
In next month's Design Techniques I'll continue the mini-series of articles that focus on designing classes and objects. Next month's article, the fourth of this mini-series, will discuss designing objects for proper cleanup at the ends of their lifetimes.
Software design is subjective. Your idea of a well-designed program may be your colleague's maintenance nightmare. In light of this fact, I am trying to make this column as interactive as possible.
I encourage your comments, criticisms, suggestions, flames -- all kinds of feedback -- about the material presented in this column. If you disagree with something, or have something to add, please let me know.
You can either enter a comment via the form at the bottom of the article or participate in a discussion forum devoted to this material.