Re: OOP Aggregation
From: Niki Estner (niki.estner_at_cube.net)
Date: 06/28/04
- Next message: Michael C: "Hey Jon Skeet"
- Previous message: Kai Bohli: "Mixing text and binary data in the same file."
- In reply to: John Wood: "Re: OOP Aggregation"
- Next in thread: John Wood: "Re: OOP Aggregation"
- Reply: John Wood: "Re: OOP Aggregation"
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 29 Jun 2004 01:54:45 +0200
They probably thought that many common applications of the decorator pattern
could be easily solved using events. (Add functionality at runtime by
overriding some event) Also, delegates are a lot cleaner and simpler than
good ol' function pointers, and if your "mother objects" contained
replaceable delegates instead of virtual functions, the kind of
"runtime-inheritance" you had in mind would be easily possible. If the
object's clients only access the object by a well-defined set of interfaces,
you could only replace one of those interfaces, leaving the others
unchanged, and introduce new behaviour this way.
Of course, all these solutions (which are the typical C# solutions) require
provisions on the parent class side, and some special design on the client
side.
Thanks to IL it's quite easy nowadays to create code at runtime, so creating
some proxy class on-the-fly from metadata would be entirely possible, too.
So, in the end I still think you have plenty of options to choose from; And
I do remember good old windows-message-handlers that did all kinds of "dirty
tricks" to re-route messages at runtime. That is, I do remember all those
debugging sessions...
Niki
"John Wood" <j@ro.com> wrote in
news:%23HWBOLVXEHA.1144@TK2MSFTNGP10.phx.gbl...
> Thanks for your thoughts.
>
> A long time ago I implemented something very hacky in COM where I would
> synthetically add support for new interfaces into an existing instance
(that
> didn't support aggregation). Sounds similar to your suggestion re
> reflection... I think I've matured enough not to try anything like that
> again! :)
>
> It's true, the decorator pattern is the most common (and probably best)
> solution available today -- but it does seem like a common and legitimate
> problem that would warrant native support in a popular language such as
C#.
>
> I really don't like the idea of manually delegating each method, because
(a)
> you lose the ability to cast to base classes of the original
implementation
> and (b) you have to maintain those delegates and keep the, in sync.
>
> In my mind, it's one of the biggest stumbling blocks of an extensible
object
> oriented system. You create classes, you want to allow other vendors to
> 'plug-in' their extensions in the form of derived classes so they can
> override various bits of functionality, but the 'plugging in' doesn't
occur
> until after instantiation when it's too late.
>
> But there just isn't a way to do this neatly in C# (or C++ for that
matter).
> I think we really need native support for the decorator pattern in C#.
>
> --
> John Wood
> EMail: first name, dot, last name, at priorganize.com
> "Niki Estner" <niki.estner@cube.net> wrote in message
> news:%23W1dJ$UXEHA.3476@tk2msftngp13.phx.gbl...
> > Let's assume for a moment we were real IL-assembler cracks and could
bend
> > the CLR in any way we wanted: We could (in theory) reallocate the
instance
> > of the old class we're given to make room for the additional members in
> the
> > new class and modify the virtual function table pointer, and the
interface
> > pointers and metadata pointers to point to the new classes ones. If I
got
> > you right, that's roughly what you had in mind?
> > First of all: This is (almost) possible. You could simply allocate an
> > instance of the new class, and copy each member (using reflection) from
> the
> > old class into the new one. Modify all pointers to the old instance to
> point
> > to the new one (probably the ugliest part) and you're done.
> > There are major drawbacks in this approach, namely that it's hard to
> > identify all pointers to the old instance (think of locks or event
> > subscriptions) and that you don't really know the internal state of the
> > "old" object when you "apply" your new class.
> > For your second question: COM had a concept called "aggregation" in
which
> a
> > COM object could expose some other object's interfaces transparently as
if
> > they were it's own ones, btu I don't know how to recreate that in the
.net
> > environment.
> > I think I read somewhere that Smalltalk supported something like you
> > suggested, but that's all i know about it - maybe you can get some ideas
> > from looking at that language.
> > IMO the idea behind a OOP language *is* to restrict what is possible on
> > objects/classes/interfaces; Otherwise we could all build C structures
with
> > function pointers - you could do *anything* with those...
> >
> > That said, the decorator pattern (which you described) is probably by
far
> > the most common and reliable solution to this problem.
> >
> > Niki
> >
> > "John Wood" <j@ro.com> wrote in
> > news:%23jPdOCUXEHA.4032@TK2MSFTNGP11.phx.gbl...
> > > Let's say you're provided with an instance of a class. The
instantiation
> > > takes place in another module that you have no control over.
> > >
> > > However, you've extended that class with your own value-added
> > functionality.
> > >
> > > In C#, given such an instance, and a derived class, there's no way to
> > > 'attach' the instance to the class -- you have to either change the
way
> > the
> > > class was instantiated (not possible in this case), or wrap the class
> and
> > > delegate each function (a concept known as aggregation).
> > >
> > > I'm sure I've asked this question on the group before, and I settled
for
> > > aggregation. But I just don't like it.
> > >
> > > I was wondering if anyone had any thoughts on this... ideas of more
> > elegant
> > > work-arounds / design patterns... solutions in other languages etc.
> > >
> > > Thanks.
> > >
> > > --
> > > John Wood
> > > EMail: first name, dot, last name, at priorganize.com
> > >
> > >
> >
> >
>
>
- Next message: Michael C: "Hey Jon Skeet"
- Previous message: Kai Bohli: "Mixing text and binary data in the same file."
- In reply to: John Wood: "Re: OOP Aggregation"
- Next in thread: John Wood: "Re: OOP Aggregation"
- Reply: John Wood: "Re: OOP Aggregation"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
