PROPOSAL: Improved Support for Optional Object Behaviors at Runtime
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
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.
More information about the coin-dev