AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |
Back to Blog
Java Event Listener Pattern4/8/2021
The removal of this member variable removes the association between the ConcreteObserver and the State class.While there are numerous useful articles on the topic of the Observer Pattern, and its implementation in Java, many focus on the strict implementation of the pattern in Java, rather than on the idiosyncrasies and common issues developers using the Observer Pattern in Java will experience.
Java Event Listener Pattern How To Approach SomeThis article is by no means comprehensive and many of the intricacies of this pattern are beyond the scope of a single article, but when complete, the reader will understand not only the Observer Pattern, but its common peculiarities in modern Java and how to approach some of the most common issues that arise when implementing the Observer Pattern in Java.For example, if an application focuses on numeric data processing, this data may be displayed on a Graphical User Interface (GUI) using a spreadsheet or a graph, or both: When the underlying numeric data is updated, the corresponding GUI components should be updated accordingly. ![]() This simple solution quickly proves its inability to cope with more complex applications when more GUI components are added. For example, if there are 20 GUI components that depend on the numeric data, the object that manages this numeric data would be required to maintain a reference to these 20 GUI components. When the number of objects that depend on the data of interest grows, the coupling between the manager of the data and the objects dependent on this data becomes more unrulely. Informally, the objects interested in the data tell the manager, Let me know when a change occurs to the data. Furthermore, after an object has been registered for updates to the data of interest, it can be unregistered, ensuring that the manager no longer notifies the object of changes that occur to the data of interest. In the context of the original GoF definition, the object that is registered for updates is called an observer, the manager of the data of interest is called a subject, the data of interest is called the state of the subject, the process of registering an observer is called attaching, and the process of unregistering an observer is called detaching. As previously stated, this pattern is also called the Publish-Subscribe pattern, since the clients subscribe observers to a subject and when updates are made to the state of the subject, the subject publishes these updates to the subscribers (this design pattern is expanded to a common architecture, called the Publish-Subscribe Architecture ). Pulling these concepts together into a single picture, we obtain the following class diagram. This provides the ConcreteObserver with a reference to the ConcreteSubject, from which the State will be obtained when the observer is notified of a change to the state. Simply, the ConcreteObserver will be notified of an update to the subject, at which time, the ConcreteObserver will use the reference to the ConcreteSubject obtained through its constructor to obtain the State of the ConcreteSubject, ultimately storing the retreived State object under the observerState attribute of the ConcreteObserver. In the classic case, when an observer is notified of a change to the state of the subject, the observer is responsible for obtaining the state of the subject directly from the subject. This requires the observer to maintain a reference to the subject from whom the state will be obtained (a circular reference, where the ConcreteSubject maintains a reference to the ConcreteObserver in its list of registered listeners, and the ConcreteObserver maintains a reference to the ConcreteSubject that can be used to obtain the Subject of the ConcreteSubject ). Apart from obtaining the updated state, the observer has no real association with the subject to which it is registered (all the observer cares about is the State object, not the Subject itself). ![]() ![]() This association is changed to an association between the ConcreteObserver and the State and to a weaker dependency between the Observer and the State (for more information on the differences between associations and dependencies, see Martin Fowlers article on the topic). For a visualization of this concept, see the ConcreteObserver in the illustration below. In many cases, the use of an abstract class for the Subject does not provide extra flexibility or extensibility and therefore, it simplifies a design to collapse this abstract class and concrete class into a single, concrete class. In some cases, a concrete observer does not need to store the new state of the Subject, but rather, simply view the state of the subject at the time the state is updated. For example, if an observer prints member variables of the updated state to standard output, the observerState member variable can be removed.
0 Comments
Read More
Leave a Reply. |