Conditional Execution - Building Java Programs: A Back to Basics Approach - page 286

2. No one method should do too large a share of the overall task. One subdi-
vision of a company cannot be expected to design and build the entire product line
for the year. This system would overwork that subdivision and would leave the other
divisions without enough work to do. It would also make it difficult for the subdivi-
sions to communicate effectively, since so much important information and responsi-
bility would be concentrated among so few people.
Similarly, one method should not be expected to comprise the bulk of a program.
This principle follows naturally from our first heuristic regarding cohesion, because a
method that does too much cannot be cohesive. We sometimes refer to methods like
these as “do-everything” methods because they do nearly everything involved in
solving the problem. You may have written a “do-everything” method if one of your
methods is much longer than the others, hoards most of the variables and data, or
contains the majority of the logic and loops.
In the BadBMI program, the person method is an example of a do-everything
method. This fact may seem surprising, since the method is not very many lines long.
But a single call to person leads to several other calls that collectively end up doing
all of the work for the program.
3. Coupling and dependencies between methods should be minimized. A
company is more productive if each of its subdivisions can largely operate indepen-
dently when completing small work tasks. Subdivisions of the company do need to
communicate and depend on each other, but such communication comes at a cost.
Interdepartmental interactions are often minimized and kept to meetings at specific
times and places.
When we are programming, we try to avoid methods that have tight coupling .
Coupling
An undesirable state in which two methods or processes rigidly depend
on each other.
Methods are coupled if one cannot easily be called without the other. One way to
determine how tightly coupled two methods are is to look at the set of parameters one
passes to the other. A method should accept a parameter only if that piece of data
needs to be provided from outside and only if that data is necessary to complete the
method's task. In other words, if a piece of data could be computed or gathered inside
the method, or if the data isn't used by the method, it should not be declared as a
parameter to the method.
An important way to reduce coupling between methods is to use return state-
ments to send information back to the caller. A method should return a result value
if it computes something that may be useful to later parts of the program. Because it
is desirable for methods to be cohesive and self-contained, it is often better for the
program to return a result than to call further methods and pass the result as a
parameter to them.