Defines a one to many relationship between the Subject (the object being observed) and the Observers
where the Observers are notified of changed state in the Subject.
We have a Temperature object and we want to log the changes to the temperature.
Using OOPS we would have to modify the Temperature class.
Using AOP we can Introduce new behaviour without touching the original class.
We already have a logging utility class and we don't need to change that either.
There is no need for it to know about the Temperature class.
Again we can Introduce new behaviour.
The jboss implementation of the pattern
Observer - the interface "implemented" by the Observer
Subject - the interface "implemented" by the Subject
The exisiting application that knows nothing about the Observable pattern
Temperature - simple POJO holding a temperature value in its state
LogUtil - simple POJO that logs to System.out
To integrate the two classes we write an Introduction for
that tells it log the changes in Subjects.
LogUtilObserver - makes
into a generic Observer without changing the original code
Now we use AOP to tie it all together
jboss-aop.xml - the JBossAOP deployment description
The test class
ObserverableTest - A simple test
It doesn't look very exciting but ...
Received Notification: Temperature=10
We have taken two existing POJOs that know nothing about the Observable pattern and integrated them using AOP.
The only code we had to write was how to handle the change notification: LogUtilObserver which is exactly what you want to write when you are the integerator
JBoss has already implemented the Observable pattern, we don't have to write this boiler plate code.
AOP is a very powerful tool for integrating reusable components without touching the original code.
You no longer have to repeat boiler plate code in all classes just in case somebody might want a particular feature - a boring task that is prone to error and difficult to change when it is spread across many classes
Things to try
Use AOPRemoting to make this pattern distributed