Java Reference
In-Depth Information
9.4.1
Basic object-oriented philosophy
Though standards cannot dictate good design, they can eliminate some bad
designs. By following these basic principles, which may be targets for some
coding standards, we hope to develop more straightforward, flexible designs:
In general, classes should be things.
It sounds elementary, but a surprising
number of object-oriented designs try to encapsulate process. This type
of design makes it easy to accumulate functionality into one, amorphous
blob that does all of the work, instead of factoring the process across a
number of objects. Two words that are commonly used to short-circuit
this rule are
manager
and
process
. If a program has classes such as
RepaintingProcess
,
InventoryProcessor
, or
PurchaseProcessManager
,
then usually it is time to refactor.
Methods should be single actions.
Methods should be actions that do one
thing, and they should be descriptively named.
Methods should be short and easy to understand.
Different coding stan-
dards have different metrics for simplicity. Some that I like are:
The method body, minus cleanup, should be able to fit on a single
screen. (I once met a lazy but innovative programmer who set his
font size incredibly small to pass code reviews.)
A method should be understandable in 30 seconds.
A method should be less than a specified number of lines or words.
You should choose the simplest approach that will work.
This is an extreme
programming technique that values readability and cycle time over a
couple of bytes of memory and a few cycles of speed.
We are shooting for universal simplicity and clarity, and it is an elusive goal.
The identifiers that we choose to
describe
our programs will have a surprising
impact on the way that we
think
about our programs, all the way through the
life cycle. Simple and descriptive names can help the cause for short, simple
method implementations. Short and simple methods can make a dramatic dif-
ference in maintenance costs over time.
9.4.2
Low-level design considerations
We've discussed basic, high-level details, but we also need to examine conven-
tions at a decidedly lower level. The application of these low-level concepts has
some long-term implications that aren't always clear at implementation time.
Let's look at some rules.
