Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

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

  • Print
  • Feedback
In last month's Design Techniques column, I told half of the method design story: minimizing method coupling. In this month's installment, I'll reveal the other half of the story: maximizing method cohesion.

As with last month's column, "Designing fields and methods," the principles discussed may be familiar to many readers, as they apply to just about any programming language. But given the vast quantity of code I have encountered in my career that didn't benefit from these basic principles, I feel it is an important public service to address the basics in the early installments of this column. In addition, I have attempted in this article to show how the basic principles apply in particular to the Java programming language.

Cohesion

Methods do things. On a low level, they do things such as accept data as input, operate on that data, and deliver data as output. On a higher level, they do things such as "clone this object," "print this string to the standard output," "add this element to the end of this vector," and "add this much coffee to this cup object."

Minimizing coupling (the topic of last month's article) requires you to look at methods on a low level. Coupling looks at how the inputs and outputs of a method connect it to other parts of the program. By contrast, maximizing cohesion requires that you look at methods on a high level. Cohesion looks at the degree to which a method accomplishes one conceptual task. The more a method is focused on accomplishing a single conceptual task, the more cohesive that method is.

Why maximize cohesion?

The more cohesive you make your methods, the more flexible (easy to understand and change) your code will be. Cohesive methods help make your code more flexible in two ways:

  1. If your method is focused on a single conceptual task, you can more easily choose a method name that clearly indicates what your method does. For example, a method named int convertOzToMl(int ounces), which converts ounces to milliliters, is easier to comprehend at first glance than a method named int convert(int fromUnits, int toUnits, int fromAmount). At first glance, you could guess that the convert() method may be able to convert ounces to milliliters, but even if that were so, you would need to do more digging to find out what fromUnits value represents ounces and what toUnits value represents milliliters. The convertOzToMl() method is more cohesive than the convert() method because it does just one thing, and its name indicates what that thing is.

  2. Cohesive methods help make your code more flexible because changes are easier to make when you can draw upon a set of methods, each of which performs a single conceptual task. Cohesive methods increase the odds that when you need to change a class's behavior at some point in the future, you'll be able to do so by writing code that invokes existing methods in a new way. In addition, changes to an existing behavior are more isolated if that behavior is encased in its own method. If several behaviors are intermixed in a single (non-cohesive) method, changes to one behavior may inadvertently add bugs to other behaviors that share that same method.


Low cohesion

As an example of a method that is not very functionally cohesive, consider this alternate way of designing a class that models coffee cups:

  • Print
  • Feedback

Resources
  • 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