|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Page 2 of 5
Because the event model described here is used by JavaBeans, the AWT (1.1 and beyond), and Swing, I will make the claim that
this is the idiomatic way to implement the observer pattern in the Java language. At the end of this article, I'll explain
why I don't feel the Observer/Observable types from java.util make the grade.
If you are familiar with the Gang of Four book, or any other book of patterns or idioms, you will recognize in the coming text the customary style of presenting patterns. Typically, pattern descriptions all adhere to a common template (that is, they use a common set of text subheadings).
For example, the template I will use for all the idioms I describe in this column has the following form:
Idiom name
The template used to describe patterns varies from book to book, but usually remains the same for all the patterns presented in one book (or in this case, in one column). The template shown above is one I concocted for my Flexible Java project, and I welcome any suggestions you may have as to how it can be improved.
Intent
Enable interested objects (listeners) to be notified of a state change or other events experienced by an "event generator."
Also known as
Observer, Dependents, Publisher-Subscriber
Example
One recent afternoon, I was sitting in my makeshift office at home, trying to think of a good example for explaining Java's
event model in a Java class I was teaching. I was having trouble thinking of a decent example, when the phone rang. I got
up, walked over to the phone, answered it, and had a short conversation. After I hung up, I realized I had my example.
What if, I asked myself, I had to design a software system that modeled a phone and all the objects that might be interested in knowing it was ringing? Certainly people in vicinity of the phone (i.e.,in the same room or house) might be interested in knowing it was ringing. In addition, an answering machine might want to know, as would a fax machine and a computer. Even a secret listening device may want to know, so it could surreptitiously monitor conversations.
I realized the interested parties might change as my program executed. For example, people might enter and leave the room containing the phone. Answering machines, computers, or top-secret listening devices might be attached to and detached from the phone as the program executed. In addition, new devices might be invented and added to future versions of the program.
So what's a good approach to designing this system? Answer: Make the telephone an event generator.
Context
One or more objects (recipients) need to use information or be notified of state changes or events provided by another object (the information provider).
The problem
In Java, one object (the information provider) customarily sends information to another object (the recipient) by invoking
a method on the recipient. But to invoke a method on the recipient, the information provider must have a reference to the
recipient object. Furthermore, the type of that reference must be some class or interface that declares or inherits the method
to invoke. In a very basic approach, the provider holds a reference to the recipient in a variable whose type is the recipient's
class.