My question is whether there is a similar pattern to Observer that does not imply a state change in the observed object. The following is a concrete example:
I have a ConnectionFactory class which is responsible for creating JDBC database connections. Now I have the need to do something with every connection right after it has been created (specifically, I need to set a user-defined variable in the MySQL session) but I don’t want to do it in the ConnectionFactory class since I feel this is something that goes beyond its responsibilities.
I have considered making ConnectionFactory extend java.util.Observable and having an Observer class that will be notified every time a connection is created. However it seems that this approach is incorrect, since the Observer pattern implies that the observed object is being observed for state changes, but the state of ConnectionFactory does not change at all when a connection is created.
As you can see, I have to go around this issue by simulating a state change before calling notifyObservers() (otherwise the observers will not be notified) and synchronizing those two statements in order to make sure that the “state changed” flag set in the first statement is still active when the second statement is executed. This kind of workaround just increases my suspicion that I have taken the wrong approach.
public class ConnectionFactory extends java.util.Observable {
public static final ConnectionFactory INSTANCE = new ConnectionFactory();
private ConnectionFactory(){};
public Connection makeConnection(){
Connection connection = null;
// ... obtain the connection ...
synchronized(this) {
this.setChanged();
this.notifyObservers(connection);
}
return connection;
}
}
public class Foo implements java.util.Observer {
@Override
public void update(Observable o, Object arg) {
Connection con = (Connection)arg;
// ... set MySQL user-defined variables ...
}
}
// Somewhere in initialization code...
ConnectionFactory.INSTANCE.addObserver(new Foo());
So there is an object that I want to observe, there is a class that must do something when the observed object fires certain events, but those events are not state changes. If the Observer pattern is not applicable, then what would be a correct approach?
2
You can:
- Use the features of Observer that you need, and ignore the other features; or
- Use some other software pattern that more closely matches what you need, or
- Don’t use a pattern at all, and simply write code that solves the problem.
Just because the Wikipedia article says that the Observer pattern is designed to notify the observer of state changes doesn’t mean that’s how you have to use it, though I would argue that any event that occurs in an otherwise immutable program is a state change.
Programmers tend to be obsessed with being “correct.” Don’t. At the end of the day, word definitions don’t matter; what matters is that your program works.
2
If don’t want to use the observer pattern, there could be another way. While I was reading your question, it became to me the idea to use the Decorator pattern.
You’ve said that you don’t want to give to the class ConnectionFactory the responsibility to set a user-defined variable in the MySQL session. Then, why don’t you decorate the Connection object with an external object, let’s say MySqlConnection, that do the job on MySQL session at creation time?
A possibile solution could be this:
public class MySqlConnection extends Connection {
// Decorated object
private Connection connection;
public MySqlConnection(Connection con) {
this.connection = con;
// Set the MySQL variable
// ...
}
// Here you can redefine Connection methods if you need
// to decorate some of them
}
public class ConnectionFactory {
// ...
public Connection makeConnection() {
// Build a connection and then decorate it (code simplification)
return new MySqlConnection(new Connection());
}
}