Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

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

What's a method to do?

How to maximize cohesion while avoiding explosion

By Bill Venners, JavaWorld.com, 05/01/98

Page 4 of 5

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.