PROPOSAL: Improved Support for Optional Object Behaviors at Runtime (original) (raw)

Artur Biesiadowski abies at adres.pl
Thu Mar 26 12:59:13 PDT 2009

Gabriel Belingueres wrote:

I don't get it. You still need an "if" after you call the getExtension method (thus the client code is not more object-oriented than using instanceof).

Idea here is that object doesn't have to implement all the interfaces it provides as 'getExtension'.

For example, you could imagine some kind of persistence-aware objects, which delegate actual work to specialized classes. Instead of having Person implementing SQLSerializable interface, you would have getExtension class returning some kind of specialized wrapper (probably retrieved from some kind of externally configurable factory), and you would have to implement only one method delegating things further instead of all the methods of SQLSerializable. Of course, it can be also implemented by having a method like getPersistenceWrapper(TypeOfPersistence) on object - but OP propose to have one method to solve all the needs.

I don't really see a major benefit here. For it to be really useful, it would have to be somehow dependent on internals of the object (in other case you can just make a application dependent static method accepting object and target interface). At the same time, there would have to be some incentive for the object to not implement the actual interface (not exposing public methods, maybe some performance benefits because of some kind of caching in wrapper object, without polluting the main object with fields required to implement the interface).

In highly dynamic systems/environment, with a bit of trickery it could be used to 'inject' interfaces into existing classes/objects. Still, I think that some kind of outside mediator is better for that rather than putting it in object itself.

Regards, Artur Biesiadowski

More information about the coin-dev mailing list