I know this is a long post, please bare with me.
That isn't true. Events can be used in many situations, its very useful
pattern when applied correctly.
am hoping there is a way to get around it.
I am working a small project containing (at the moment) two beans, the
first bean basically monitors the temperature of a room and the second
bean is supposed to recieve the new data every time the temperature
changes and I am at a total loss as to how to do this.
[snip]
This is an excellent reason for having all changes to a variable go through
a setter.
In a way, yes, but in another no. Read below.
It's next to impossible to detect when the value of a field
changes; it's trivial to add behavior to a setter.
In general, public getters and setters can be a bad (read: often
abused) thing. For example, a TemperatureSensor class shouldn't allow
any client to set the temperature, it should handle that on its own.
I read an article [1] which helped me come to that conclusion. Although
the authors views are a *little* extreme, the general principal is
good.
Objects generally should have the following three parts:
* Interface: A way to interact with an object
* Behaviour: The "observable" outcome of interaction.
* Implementation: The hidden cause of the behaviour.
Often times people open up the interface to expose all of the
underlying implementation. Specifically, Java programmers often expose
properties (fields) in the interface that should instead be part of a
hidden state. This is what comes when one blindly follows the
ubiquitous advice that "you should use getters and setters."
The implementation manipulates the state of the object, which should
often be a hidden state. This hidden state is useless to clients of
the object, and may not have the same format from version to version,
or even object to object. The interface should expose what I call
"observable state". In the OP's problem, the observable state would be
the current Temperature.
If you find that some object's state is being manipulated outside of
the defining class, try to find a way to make that manipulation a
method (behaviour) of that object's class instead. Fowler [2] has some
good advice on how to change where behaviour occures.
With those goals in mind, here is how I might define your temperature
monitoring class:
class TemperatureSensor {
private Temperature currentTemp;
final List<TemperatureChangeListener> listeners =
new ArrayList<TemperatureChangeListener>();
public void addTemperatureChangeListener(
TemperatureChangeListener listener) {
listeners.add(listener);
}
/** I'm assuming that the sensor is probably
* going to run in its own thread.
*/
protected void updateTemp() {
Temperature temp = pollTempurature();
if (!temp.equals(currentTemp)) {
setTemp(temp);
}
}
/* Notice that this is *private* for a reason. */
private void setTemp(Temperature temp) {
TemperatureChangeEvent tce =
new TemperatureChangeEvent(this, currentTemp, temp);
currentTemp = temp;
for (TemperatureChangeListener listener: listeners) {
listener.temperatureChanged(tce);
}
}
/**
* Device specific, and should probably
* block the current thread for a little while so that
* it can be called in a loop without taxing the CPU.
*/
protected abstract Temperature pollTemperature();
}
[1] "Why getter and setter methods are evil"
<
http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html>
[2] "Refactoring: Improving the Design of Existing Code"
<
http://www.amazon.com/Refactoring-Improving-Design-Existing-Code/dp/0201485672>
