Java Reference
In-Depth Information
I learned to use the tools and techniques of the experts.
As a programmer, I
attend many conferences to learn about best practices, and to find the
new frameworks and tools that are likely to make a difference on my
projects.
I did what the experts did.
I learned the easiest line and practiced it in my
mind. We can do the same thing as programmers, by using design pat-
terns detailing successful blueprints to difficult architectural problems.
I learned from the mistakes before me.
The first time down a rapid, it's
usually not enough to take a good plan and plunge on through, torpe-
does be damned. Good plans can go bad, and it's important to know
how to react when they do. As a programmer, I do the same thing. I am
a huge fan of “merc talk,” or the stories told around the table in the caf-
eteria about the latest beast of a program. This is the realm of the
antipattern.
When I was told how to run State Line Falls, I asked what-if questions. What
should my precise angle be? How can I recover if I drift off that angle? How far
left is too far? What's likely to happen if I miss my line and flip? I got answers
from locals who had watched hundreds of people go down this rapid with
varying degrees of success. The answers to these questions gave me a mental
picture of what usually happened, what could go wrong, and what places or
behaviors to avoid at all cost. With this knowledge, I got the confidence that it
took to run the rapid. I was using design patterns and antipatterns.
1.2
Using design patterns accentuates the positive
Design patterns are solutions to recurring problems in a given context. A
good example is the Model-View-Controller design pattern introduced in
chapter 3. It presents a generic solution to the separation of the user interface
from the business logic in an application. A good design pattern should repre-
sent a solution that has been successfully deployed several times. At State Line
Falls, when I read about the successful line in guidebooks and watched experi-
enced kayakers run the rapid, I was essentially using design patterns. As a pro-
grammer, I use them for many reasons:
Proven design patterns mitigate risk.
By using a proven blueprint to a
solution, I increase my own odds of success.
Design patterns save time and energy.
I can effectively use the time and
effort of others to solve difficult problems.
