Ask Questions?

View Latest Questions



Java: Cohesion
Posted on: July 26, 2006 at 12:00 AM
Sometimes it will be convenient to do two things in a function because you're working on the same data.

Java: Cohesion

Each function should do only one thing. This should be done so that the conceptual unit can be understood easily. Sometimes it will be convenient to do two things in a function because you're working on the same data.

Try to resist this temptation.
Make two functions if you reasonably can.

For example, if you write a function to read a file of numbers into a vector (eg, readVector(v)), that's all the function should do.


If you know that you also need the sum of the numbers, Here are three ways to solve the problem of reading a vector and summing the elements.

  • Criminally bad. As elements as read it, it's probably most efficient to add them to a global variable. The call would then look like
    // CRIMINALLY BAD. Not obvious that sum is in global variable. readVector(v); > Not only does this function do more than one thing, but the name and call give no clue that it is doing more. The hidden reference to a global variable also increases the coupling (connections between parts of a program), which is bad.
  • Bad. To avoid global variables, which are almost always bad, return the sum as the value of the function.
    // BAD.  Function does two things, and one is unobvious.
    x = readVector(v);
    This is bad because it isn't obvious from that name that a value is returned or what that value might be. It does reduce the coupling and at least it is obvious in this use that it does return a (unknown) value.
  • Poor. A better alternative is
    // POOR.  Understandable, but not very reusable.
    x = readVectorAndComputeSum(v);  
    This clarifies the processing, but doesn't produce simple, reusable building blocks.
  • Good. A better way to do it is two write two functions.
    // GOOD.  The two actions are separated and given good names.
    x = sumVector(v);
    This is better because each function does one clear thing (ie, is cohesive). These function building blocks are also much more likely to be reusable. But what about the efficiency of this solution. Isn't the extra function call less efficient? Yes, but the amount is so small that it isn't worth more than a few nanoseconds. If this was in an extremely high performance loop (eg, rendering real-time graphics), then it might be worth thinking about optimizing. What you should optimize for is the readability of programs -- programmer (ie, your) time is worth much more than a few machine cycles. And the extra time you take to type in an extra function is easily repaid in having a simpler program to work on.
Copyleft 2003 Fred Swartz MIT License, Last update: 2003-08-29