Java's current scheme of using Classes and Interfaces to handle objects is generally adequate, but there's one specific scenario where it's a royal pain: when you've got an already-instantiated object of some other class (possibly generated by a factory method of some other class beyond your control)
that needs to be thinly wrapped to filter data passing through it.
Sure, you can create a new class that has the already-created object as a private member, then implement the object's entire interface and delegate everything to the object... but if you spend even a minute thinking about where this is the most useful (say, JDBC-related classes implementing ResultSet, Statement, Connection, etc) and look at the sheer number of methods required by most of 'em, something that SHOULD be trivially easy to do quickly becomes a 30-90 minute exercise in manual labor.
Worse, if you're wrapping an object that some other method actually NEEDS to access as its native type above and beyond the generic interface (say, OracleConnection vs Connection), the scheme quickly starts to fall apart and get ugly... even if you implement the subclass' methods, the signature will still be wrong unless you try to extend that class.
What I propose is a lightweight construct called "filter" to sit proudly alongside "interface" and "class" (or, more accurately, cover them with duct tape *grin*). "Filter" methods would have three scopes:
* public methods with the same name and signature as the wrapped object would be called instead of that object's methods. The wrapper method could access the wrapped class' method using "wrapped." the way a subclass uses "super.".
* protected methods with the same name and signature as the wrapped object would ONLY be called if the wrapped object were explicitly cast to the wrapper type. In other words, naive clients call the original method, knowing clients can call the wrapped one.
* private methods, as expected, can only be called by the wrapper's own methods.
public filter FooWrapper {
// public methods override the wrapped method outright
public int someMethod(String value) {
// do something first
return wrapped.someMethod(internalMethod(value));
}
// protected methods override wrapped method ONLY if object explicitly cast to wrapper
protected String toString() {
return "value returned when wrapped object explicitly cast to wrapper";
}
// private methods can only be called by the wrapper
private String internalMethod(String value) {
return "foo-" + value;
}
}
Want to make some existing object created by somebody else's factory method implement some particular interface (say, Observer) after the fact?
public filter Chaperone implements Observer {
// implementation of Observer interface that calls one of
// the wrapped object's methods when the object it's observing fires off a message...
}
FactoryMadeObject theObject = someObject.createFactoryMadeObject();
Chaperone sentry = new Chaperone().wrap(theObject);
// voila!
theObject.getClass().getName() --> FactoryMadeObject
(theObject instanceof FactoryMadeObject) == true
(theObject instanceof Observer) --> true
(theObject instanceof Chaperone) --> true
theObject.getWrapper().getName --> "Chaperone"
theObject.getWrappers() --> List of wrappers, from the outermost to the Class of the wrapped object.
OK, I'll admit this isn't entirely a new idea. In other languages, this would be classified as a tiny subset of multiple inheritance... something Gosling apparently hated with a passion and was determined to prohibit in any form. Still, I think that something along the lines of this idea would probably get a standing ovation at a Java programmer's conference (followed moments later by angry, livid tirades from the tiny handful of purists who oppose the sullying of Java's academic purity with something as lowbrow as multiple inheritance in any form)...