[MUD-Dev] Spoofs

[Daniel.Harman at barclayscapital.com]

From: John Buehler [mailto:johnbue at msn.com]
> Daniel Harman writes:
 
>> http://www.devx.com/free/mgznarch/vcdj/1999/julmag99/atlinherit1.asp

>> If you've seen all this before then its probably not very
>> interesting, but when I first saw it I was impressed.
 
> Well, it's an interesting treatment, but it appears to be a funky
> way of doing aggregation.  The funkiness shows up in that it uses
> templates, which tend to produce code bloat.  Why not simply
> encapsulate the behavior of the base 'class' in a component and
> aggregate it in the derived 'class'?  It gives you one copy of the
> two sets of code and leaves aggregation control in the child
> component, which is the essential point of the template approach.
> Yes, it's more aggravating because you're forced to strictly
> separate the functionality of the two components, create
> interfaces, QueryInterface and all that gubbage.  But it gives you
> a far cleaner separation of code.  Properly designed, you have a
> greater opportunity for component and contract reuse.

In many circumstances I agree, but it depends on the complexity of
your class hierarchy and how the objects interelate. The problem
with your approach is that if want to use functionality of the child
component, but no interest in the functionality of the parent in
this instance, then the parent still gets instantiated by the
child. Or do you you have to add code to the child to dynamically
instantiate a parent on an as needed basis?

e.g.

  You have this:


                  IMessageMap
                        |
    CActiveX      CMessageMap
        \___        ___/
            \      /
             \    /
            CWindow 

Now say you just want to use some functions in CWindow but don't
want all the other stuff. You can't traditionally. You can with the
ATL approach if you've encapsulated properly (and without having to
create a CWindow2 or something like that which doesn't inherit)

Alteratively, you want CWindow, but you aren't happy with the
Message map implementation, this approach lets you redefine the
class hierarchy:


                  IMessageMap
                        |
    CActiveX      CFunkyMessageMap
        \___        ___/
            \      /
             \    /
            CWindow


Even better, CActiveX control is able to have a dependency on
IMessageMap functions being available in the class - it allows
siblings to communicate directly because they have a templated
reference to the most derived object, and all without dynamic (read
slow) upcasting or virtual functions.

Even my example here doesn't fully explain the elegance, because its
only one level of inheritence deep (I don't count the interface
;). When you start having multiple levels, and every class has two
template params, one is the most derived class, the other is what
the class should use as its base. This allows you to fully control
the hierarchy without hardcoding it into the classes.

The bloat you mentioned isn't really a fair criticism, as the whole
point is that you only bring in what you need. Its anti-bloat!

The linked example does explain all this, but maybe my explanation
is helpful to see what its driving at. I do find it quite hard to
explain though :)

> It is my understanding that C# makes all this COM component stuff
> much easier to deal with.  So I'm told by my old team at
> Microsoft.  And that should make COM component development that
> much more appealing.

COM isn't actually that hard if you take the time to learn the
rules. I've heard the C# team are in direct competetion with the COM
team at MS and its a pitched battle by all accounts. Both teams
thinking the opponents approach is flawed as there are some
fundamental differences in methodology. COM wants everything to be a
black box, .net is opposite in that it thinks full reflection is of
key importance.

Dan

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev