Java Reference
In-Depth Information
rather than depart radically from it. Your investment in Java will almost surely yield value in
any language that supplants Java.
The patterns in
Design Patterns
apply to Java because, like Smalltalk and C++, Java follows a
class/instance paradigm. Java is much more similar to Smalltalk and C++ than it is to, say,
Prolog or Self. Although competing paradigms are important, the class/instance paradigm
appears to be the most practical next step in applied computing. This topic uses Java because
of Java's popularity and because Java appears to lie along the evolutionary path of languages
that we will use for decades ahead.
Why UML?
Where challenges have solutions in code, this topic uses Java. But many of the challenges ask
you to draw a diagram of how classes, packages, and other elements relate. You can use any
notation you like, but this topic uses
Unified Modeling Language
(
UML
) notation. Even if
you are familiar with UML, it is a good idea to have a reference handy. Two good choices are
The UML User Guide
(Booch, Rumbaugh, and Jacobson 1999), and
UML Distilled
(Fowler
with Scott 2000). The bare minimum of UML knowledge you need for this topic is provided
in Appendix C, UML at a Glance, page 441.
Why a Workbook?
No matter how much you read about doing something, you won't feel as though you know it
until you do it. This is true partially because until you exercise the knowledge you gain from a
topic, you won't encounter subtleties, and you won't grapple with alternative approaches. You
won't feel confident about design patterns until you apply them to some real challenges.
The problem with learning through experience is that you can do a lot of damage as you learn.
You can't apply patterns in production code before you are confident in your own skills. But
you need to start applying patterns to gain confidence. What a conundrum! The solution is to
practice on example problems where mistakes are valuable but painless.
Each chapter in this
workbook
begins with a short introduction and then sets up a series of
challenges for you to solve. After you come up with a solution, you can compare your
solution to one given in Appendix B, Solutions, starting on page 359. The solution in the topic
may take a different slant from your solution or may provide you with some other insight.
You probably can't go overboard in how hard you work to come up with answers to the
challenges in this topic. If you consult other topics, work with a colleague, and write sample
code to check out your solution, terrific! You will never regret investing your time and energy
in learning how to apply design patterns.
A danger lurks in the solutions that this topic provides. If you flip to the solution immediately
after reading a challenge, you will not gain much from this topic. The solutions in this topic
can do you more harm than good if you don't first create your own solutions.
