Java Reference
In-Depth Information
As a rule of thumb, updating an explicit parameter can be surprising to programmers,
and it is best to avoid it whenever possible.
You should minimize side effects that go beyond modification of the implicit
parameter.
Another example of a side effect is output. Consider how we have always printed a
bank balance:
System.out.println("The balance is now $"
+ momsSavings.getBalance());
Why don't we simply have a
printBalance
method?
public void printBalance()
// Not recommended
{
System.out.println("The balance is now $" +
balance);
}
That would be more convenient when you actually want to print the value. But, of
course, there are cases when you want the value for some other purpose. Thus, you
can't simply drop the
getBalance
method in favor of
printBalance
.
More importantly, the
printBalance
method forces strong assumptions on the
BankAccount
class.
ȗ
The message is in EnglishȌyou assume that the user of your software reads
English. The majority of people on the planet don't.
ȗ
You rely on
System.out
. A method that relies on
System.out
won't work
in an embedded system, such as the computer inside an automatic teller
machine.
In other words, this design violates the rule of minimizing the coupling of the classes.
The
printBalance
method couples the
BankAccount
class with the
System
and
PrintStream
classes. It is best to decouple input/output from the actual work
of your classes.
342
