Java Reference
In-Depth Information
doesn't solve any problems but instead introduces bugs, inefi cient design, low performance, and
maintenance issues. Most patterns can solve problems in design, provide reliable solutions to known
problems, and allow developers to communicate in a common idiom across languages. Patterns
really should only be used when problems are likely to occur.
Design patterns were originally classii ed into three groups:
Creational patterns —Patterns that control object creation, initialization, and class selection.
Singleton (Chapter 4, “Singleton Pattern”) and factory (Chapter 6, “Factory Pattern”) are
examples from this group.
Behavioral patterns —Patterns that control communication, messaging, and interaction between
objects. The observer (Chapter 11, “Observer Pattern”) is an example from this group.
Structural patterns —Patterns that organize relationships between classes and objects, provid-
ing guidelines for combining and using related objects together to achieve desired behaviors.
The decorator pattern (Chapter 7, “Decorator Pattern”) is a good example of a pattern from
this group.
Design patterns offer a common dictionary between developers. Developers can use them to com-
municate in a much simpler way without having to reinvent the wheel for every problem. Want to
show your buddy how you are planning to add dynamic behavior at run time? No more step‐by‐step
drawings or misunderstandings. It's plain and simple; you just utter a few words: “Let's use a deco-
rator pattern to address this problem!” Your friend will know what you are talking about immedi-
ately, no further explanation needed. If you already know what a pattern is and use it in a right
context, you are well on your way to developing a durable and maintainable application.
It's strongly suggested that you read Design Patterns: Elements of Reusable
Object‐Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and
John Vlissides (Addison‐Wesley, 1995) or Head First Design Patterns by Eric
Freeman, Elisabeth Robson, Bert Bates, and Kathy Sierra (O'Reilly, 2004). Both
are great companions to this topic and are invaluable guides for learning design
One key point regarding design patterns is that overuse or unnecessary use can be troublesome. As
soon as some developers learn new patterns, they show a great desire to use them whenever they
can. However, doing so often results in their project being bloated with singletons or overwrapping
via façades or unnecessarily complex decorators. Design patterns are answers to problems, so unless
there is a problem or a chance for a problem to appear, there is no point implementing a pattern.
To give an example, using the decorator pattern just because there is a slim chance that an object's
behavior might change in the feature introduces development complexity today and a maintenance
nightmare in the future.
Search WWH ::

Custom Search