What's a method to do?

How to maximize cohesion while avoiding explosion

1 2 Page 2
Page 2 of 2
// In Source Packet in file cohesion/ex5/CoffeeCup.java
class CoffeeCup {
    private int innerCoffee;
    private int innerCream;
    private int innerSugar;
    public void addCoffee(int amount) {
        innerCoffee += amount;
    }
    public void addCream(int amount) {
        innerCream += amount;
    }
    public void addSugar(int amount) {
        innerSugar += amount;
    }
    //...
}

These methods are more functionally cohesive because they each do one thing. This design is more flexible because the programmer can call any of the methods at any time and in any order.

Cohesion is high-level

Although all of the examples of functionally cohesive methods so far have accepted, processed, and returned a very small amount of data, this is not a characteristic shared by all functionally cohesive methods. Cohesion means doing "one thing" on a high level, as in performing one conceptual activity -- not at a low level, as in processing one piece of data. For example, perhaps your virtual café has a regular customer, Joe, who always wants his coffee prepared with 30 parts coffee, 1 part cream, and 1 part sugar. If so, you could create a method such as:

// In Source Packet in file cohesion/ex5/VirtualCafe.java
class VirtualCafe {
    private static final int JOES_CREAM_FRACTION = 30;
    private static final int JOES_SUGAR_FRACTION = 30;
    public static void prepareCupForJoe(CoffeeCup cup, int amount) {
        cup.addCoffee(amount);
        cup.addCream(amount/JOES_CREAM_FRACTION);
        cup.addSugar(amount/JOES_SUGAR_FRACTION);
    }
}

The prepareCupForJoe() method is functionally cohesive even though, on a low level, it performs exactly the same function as the add() method, shown earlier, that wasn't functionally cohesive. The reason is that, conceptually, this method is preparing a cup of coffee for Joe, just the way he always likes it. The add() method, on the other hand, was adding coffee to a cup, and incidentally, also adding cream and sugar. Although add(), a member of class CoffeeCup, did not allow coffee to be added to a cup without also adding cream and sugar, prepareCupForJoe() involves no such restriction. Because prepareCupForJoe(), a member of class VirtualCafe, invokes addCoffee(), addCream(), and addSugar() from class CoffeeCup, it in no way prevents other methods from filling a cup with only coffee and cream, or any other combination in any proportion.

Method explosion

Although these guidelines can help you create code that is more flexible, following the guidelines too strictly can lead your code down the wrong alley. Factoring methods, such as modify(), into more cohesive methods, such as add(), releaseOneSip(), and spillEntireContents() leads to more methods. At some point your class will get difficult to use simply because it has too many methods.

As with all guidelines, you must use this one wisely and selectively. In general, you should maximize the cohesion of your methods. In general, you should avoid passing control down into a method. But there are some circumstances in which you should violate both of these principles.

For example, you may have a class that must respond differently to each of 26 different keypresses, one for each letter of the alphabet. Passing down the key to a method named void handleKeypress(char key) could reasonably be called passing down control, especially if the first thing you do is a switch(key), then have a case statement for each letter of the alphabet. But in this case, a single handleKeypress(char key) likely is easier to use and just as easy to understand as 26 separate methods handleAKeypress(), handleBKeypress(), handleCKeypress(), and so on.

Thus, you need to strike a balance between maximizing method cohesion and keeping the number of methods in a class to a reasonable level. There's no hard and fast rule to help you do this -- you just have to use your own judgment. After all, that's why they pay you the big bucks.

Cohesion in coding and writing

When you write software in a commercial environment, you aren't just writing down instructions for a machine, you are communicating your intentions to other human beings -- fellow programmers who may someday need to read your code to understand how to use or modify it. In a sense, when you code, you are writing, and many of the principles of good writing can be applied to good coding.

For example, a well-named, cohesive method in a Java program is analogous to a well-written paragraph in expository writing. A paragraph should have a main idea, usually stated in a topic sentence. Just as the topic sentence indicates to a prose reader the main idea of a paragraph, a descriptive method name tells a code reader what service that method performs. In a paragraph, every sentence should directly support the main idea. A paragraph, like a cohesive method, should be about one thing (indicated by the topic sentence), and all the sentences in the paragraph should be focused on that one thing.

A paragraph that doesn't stick to its topic, like a method that isn't cohesive, is harder to understand than a paragraph that focuses exclusively on its topic. Coupling, the topic of my previous article, doesn't really have an analog in the writing domain, but as I said previously in this article, a cohesive method maps to a well-written paragraph. Another metaphor for cohesion is glue. There are many kinds of glue, some of which emanate a stronger smell than others, which may give you a headache in certain cases. One of my favorite glues was the kind of paste we used in kindergarten. The lid had a brush attached to it, and we would -- oops, I just spilled some mocha on my printout -- cut out different colors of construction paper and glue them together. Those were the days...

See what I mean? What do coupling, glue, headaches, kindergarten, mochas, and construction paper have to do with the difficulty in understanding a non-cohesive paragraph? Not much. In fact, these sentences comprise an example of a paragraph that doesn't stick to its topic.

Unfortunately, I have encountered many methods, functions, and subroutines over the years that were as much an amalgam of unrelated parts as that paragraph. And while an unfocused paragraph may be somewhat amusing to read, the unfocused functions I've encountered have usually brought me more anguish than amusement.

So please try to keep in mind as you program in Java that you aren't just giving instructions to a Java virtual machine (JVM), you are communicating through your code to your programming peers. Making your code easier to understand and change will help you earn the respect and admiration of your colleagues, but it can also help you in a more direct way. Don't forget that a few years or months (or minutes) down the road, the person called upon to maintain your code just might be you.

Conclusion

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

Next month

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.

A request for reader participation

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.

Bill Venners has been writing software professionally for 12 years. Based in Silicon Valley, he provides software consulting and training services under the name Artima Software Company. Over the years he has developed software for the consumer electronics, education, semiconductor, and life insurance industries. He has programmed in many languages on many platforms: assembly language on various microprocessors, C on Unix, C++ on Windows, Java on the Web. He is author of the book: Inside the Java Virtual Machine, published by McGraw-Hill.

Learn more about this topic

  • Source packet that contains the example code used in this article http://www.artima.com/flexiblejava/cohesion.html
  • Recommended books on Java Design http://www.artima.com/designtechniques/booklist.html
  • The discussion forum devoted to the material presented in this article. http://www.artima.com/flexiblejava/fjf/cohesion/index.html
  • Object Orientation FAQ http://www.cyberdyne-object-sys.com/oofaq/
  • 7237 Links on Object Orientation http://www.rhein-neckar.de/~cetus/software.html
  • The Object-Oriented Page http://www.well.com/user/ritchie/oo.html
  • Collection of information on OO approach http://arkhp1.kek.jp:80/managers/computing/activities/OO_CollectInfor/OO_CollectInfo.html
  • Design Patterns Home Page http://hillside.net/patterns/patterns.html
  • A Comparison of OOA and OOD Methods http://www.iconcomp.com/papers/comp/comp_1.html
  • Object-Oriented Analysis and Design MethodsA Comparative Review http://wwwis.cs.utwente.nl:8080/dmrg/OODOC/oodoc/oo.html
  • Patterns discussion FAQ http://gee.cs.oswego.edu/dl/pd-FAQ/pd-FAQ.html
  • Implementing Basic Design Patterns in Java (Doug Lea) http://g.oswego.edu/dl/pats/ifc.html
  • Patterns in Java AWT http://mordor.cs.hut.fi/tik-76.278/group6/awtpat.html
  • Software Technology's Design Patterns Page http://www.sw-technologies.com/dpattern/
  • Synchronization of Java Threads Using Rendezvous http://www-cad.eecs.berkeley.edu/~jimy/classes/rendezvous/
  • Design PatternsElements of Reusable Object-Oriented Software, In Java http://www.zeh.com/local/jfd/dp/design_patterns.html
  • Another example of obvious content from Bill Venners http://www.artima.com/bv/music/obvioussong.html
1 2 Page 2
Page 2 of 2