|
|
|
Sponsored Link •
|
|
Advertisement
|
Summary
In this installment of the Design Techniques column, I propose the "event generator" as a Java idiom. The article provides a background on the concepts of patterns and idioms, describes the observer pattern, and demonstrates the idiomatic way to implement the observer pattern in Java.
In January, I began a long series of articles about designing classes and objects. In this month's Design Techniques article, I'll continue that series but with a different approach. Up to now I have been writing in terms of design guidelines. In this article I'll be writing about idioms.
In my view, some design ideas are most effectively communicated via a set of guidelines, whereas other ideas can be communicated best as patterns or idioms. One of my main goals with this column is to "try out" material that I plan to put into my next book, Flexible Java (see Resources), by sending the material out to the public arena and getting feedback. Currently, I plan to organize Flexible Java around both guidelines and idioms, using each where it is most appropriate. In this and the next article, I'll be proposing some idioms on which I welcome any and all feedback.
I call the idiom I will propose in this article the event generator.
This idiom arises from implementing the well-known observer pattern in
Java by applying the JavaBeans/1.1 AWT/Swing event model to classes
that aren't necessarily beans or GUI components. In this article, I'll
present a backgrounder on patterns and idioms, discuss the observer
pattern, demonstrate the event generator idiom, and explain why I
don't think using the Observer/Observable
types from java.util is the best approach to implementing
the observer pattern in Java.
On patterns and idioms
In this article, I will be demonstrating the idiomatic way to implement
the observer pattern in Java. The observer pattern is one of 23 design
patterns described in the book Design Patterns: Elements of
Reusable Object-Oriented Software by Gamma, Helm, Johnson, and
Vlissides (aka the Gang of Four). This book describes patterns
that pop up again and again in object-oriented designs, independent of
implementation language. It discusses the pros and cons of each
pattern, gives advice on when each pattern is appropriate, and shows an
example of each pattern implemented in Smalltalk or C++.
The examples I include in this article are not simply Java translations of the C++ code given in the Gang of Four book, because Java has an idiomatic way to implement this pattern. Which brings me to idioms.
What is the difference between a design pattern and an idiom? The difference is one of scope. In general, both design patterns and idioms describe solutions to recurring design problems. But with a design pattern, both the problem and solution are generic enough to be independent of implementation language. An idiom, by contrast, is a low-level pattern that is specific to a programming language. For example, a design pattern might describe a way to ensure there is only one instance of a class (the singleton pattern). An idiom might describe a way to return multiple values in Java, given that the Java language doesn't have a built-in multivalued return capability. (See Resources for a link to my proposed idiom that addresses this problem.)
|
Sponsored Links
|