Mannie said:
Thanks for your reply Göran.
Whilst I do agree that one should obey the fundamental principles of OOP,I
want the trick in this case anyway.
Deriving from existing classes is simply not acceptable here: what if some
sealed class must be persisted in my OO database? I would have to resort to
a wrapper class. It creates horrible code.
Also, the name of <ExistingClass> is not known to my OO database in advance,
so any code using the database must use a wrapper (be it a derived class or
a container, it's the same in this case) for every possible Type that I wish
to persist. I simply don't want that. The nitty-gritty details of the
persistence mechanism should be irrelevant to the consuming code and so it
should not be bothered with things like its object id if it's not essential
to its reason of existence. Also, one could argue that subclassing for the
sake of facilitating some low-level technical requirement, having nothingto
do with specialization is not very good OO practice either.
More suggestions are very welcome. One other thing though - and no offence
meant to Göran - I've seen a lot of good and bad practices, patterns and
antipatterns in my career. I'm not really interested in more lectures about
them. All I want is a good answer to my question.
Regards,
Manfred
Hi Mannie,
It sounds like you're looking for something along the lines of aspect
oriented programming, or at least I've read articles on these topics
which deal with some interesting concepts (like providing proxies which
act like the instances of a class but have additional behaviour bolted
on). The typical examples used with AOP tend to be adding logging
transparently, but I think other things (like adding additional
members) may also be possible.
If you've already explored this area, apologies for wasting your time.
If you're interested in this area then... Sorry, haven't done any
myself, just read the articles. I'd suggest googling for aspect
oriented programming and seeing where you can go from there.
HTH
Damien.