CHAPTER 20 ■ OBJECTS, PATTERNS, PRACTICEReusability
Encapsulation promotes decoupling, which promotes reuse. Components that are self-sufficient and
communicate with wider systems only through their public interface can often be moved from one
system and used in another without change.
In fact, this is rarer than you might think. Even nicely orthogonal code can be project-specific. When
creating a set of classes for managing the content of a particular web site, for example, it is worth taking
some time in the planning stage to look at those features that are specific to your client, and those that
might form the foundation for future projects with content management at their heart.
Another tip for reuse: centralize those classes that might be used in multiple projects. Do not, in
other words, copy a nicely reusable class into a new project. This will cause tight coupling on a macro
level, as you will inevitably end up changing the class in one project and forgetting to do so in another.
You would do better to manage common classes in a central repository that can be shared by your
projects.
Aesthetics
This is not going to convince anyone who is not already convinced, but to me, object-oriented code is
aesthetically pleasing. The messiness of implementation is hidden away behind clean interfaces, making
an object a thing of apparent simplicity to its client.
I love the neatness and elegance of polymorphism, so that an API allows you to manipulate vastly
different objects that nonetheless perform interchangeably and transparently—the way that objects can
be stacked up neatly or slotted into one another like children’s blocks.
Of course, there are those who argue that the converse is true. Object-oriented code can lead to
tortuous class names that must be combined with method names to form even more labored
invocations. This is especially true of PEAR, where class names include their package names to make up
for PHP’s lack of support for namespaces. There is an end in sight to this now that namespaces are
poised part of the language. PEAR developers prize backward compatibility, though, so it will be some
time before the old naming conventions fall by the wayside.
It is also worth mentioning that a beautiful solution is not always the best, or most efficient. It is
tempting to use a full-blown object-oriented solution where a quick script or a few system calls might
have got the job done.
Another fair criticism is that object-oriented code can dissolve into a babel of classes and objects
that can be very hard to read. There is no denying that this can be the case, although matters can be
eased considerably through careful documentation containing usage examples.
Patterns
Recently a Java programmer applied for a job in a company with which I have some involvement. In his
cover letter, he apologized for only having used patterns for a couple of years. This assumption that
design patterns are a recent discovery—a transformative advance—is testament to the excitement they
have generated. In fact, it is likely that this experienced coder has been using patterns for a lot longer
than he thinks.
Patterns describe common problems and tested solutions. Patterns name, codify, and organize real-
world best practice. They are not components of an invention or clauses in a doctrine. A pattern would
not be valid if it did not describe practices that are already common at the time of hatching.
Remember that the concept of a pattern language originated in the field of architecture. People were
building courtyards and arches for thousands of years before patterns were proposed as a means of
describing solutions to problems of space and function.
Having said that, it is true that design patterns often provoke the kind of emotions associated with
religious or political disputes. Devotees roam the corridors with an evangelistic gleam in their eye and a