Multiple base classes in .NET - Framework and Interface Programming

[Please do not mail me a copy of your followup]

"Ben Voigt [C++ MVP]" <rbv@nospam.nospam> spake the secret code
<#oGR1MgyHHA.988@TK2MSFTNGP02.phx.gbl> thusly:

>> On the other hand, ATL does all its business with template tricks and
>> doesn't use the virtual function call mechanism very much, if at all.
>> (I can't recall right now if it uses any virtual functions or not, but
>> my recollection is that I don't recall any virtual function business
>> going on when I last studied the ATL Internals book.)
>
>
>LOL
>
>COM is built on a function dispatch table... in C++ parlance, a v-table.

COM, yes, but the mechanisms that ATL uses to implement itself are
built around templates and not virtual functions, IIRC.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.com/~legalize/book/download/index.html>

Legalize Adulthood! <http://blogs.xmission.com/legalize/>

[Please do not mail me a copy of your followup]

"Ben Voigt [C++ MVP]" <rbv@nospam.nospam> spake the secret code
<#oGR1MgyHHA.988@TK2MSFTNGP02.phx.gbl> thusly:

>> On the other hand, ATL does all its business with template tricks and
>> doesn't use the virtual function call mechanism very much, if at all.
>> (I can't recall right now if it uses any virtual functions or not, but
>> my recollection is that I don't recall any virtual function business
>> going on when I last studied the ATL Internals book.)
>
>
>LOL
>
>COM is built on a function dispatch table... in C++ parlance, a v-table.

COM, yes, but the mechanisms that ATL uses to implement itself are
built around templates and not virtual functions, IIRC.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.com/~legalize/book/download/index.html>

Legalize Adulthood! <http://blogs.xmission.com/legalize/>

On Jul 18, 2:12 pm, "Chris Mullins [MVP]" <cmull...@yahoo.com> wrote:
> "Mark Rae [MVP]" <m...@markNOSPAMrae.net> wrote
>
> > "Larry Smith" <no_spam@_nospam.com> wrote in message
>
> [Multiple Inheritence]
>
> >> Moreover, it's rarely even used in the C++ world.
>
> That's just... not right.
>
> The entire STL is full of multiple inheritence. Every C++ programmer's first
> program uses it, even if they're not aware of it (IOStream).

It certainly isn't "full of multiple inheritance". You gave one
example, and I don't think there's another. Multiple inheritance is
extremely unintuitive, hard to work with, and 99 times out of 100 it
is indicative of a bad design. 1 time out of 100 maybe you've got
something great with multiple inheritance, but one of the fundamental
philosophies of .NET is to err on the side of safety. Having been a C+
+ programmer for over 10 years, I'm praying multiple inheritance
doesn't ever see the light of day in .NET. Even single inheritance is
abused more often than not, when containment would be a much better
solution.

On Jul 18, 2:12 pm, "Chris Mullins [MVP]" <cmull...@yahoo.com> wrote:
> "Mark Rae [MVP]" <m...@markNOSPAMrae.net> wrote
>
> > "Larry Smith" <no_spam@_nospam.com> wrote in message
>
> [Multiple Inheritence]
>
> >> Moreover, it's rarely even used in the C++ world.
>
> That's just... not right.
>
> The entire STL is full of multiple inheritence. Every C++ programmer's first
> program uses it, even if they're not aware of it (IOStream).

It certainly isn't "full of multiple inheritance". You gave one
example, and I don't think there's another. Multiple inheritance is
extremely unintuitive, hard to work with, and 99 times out of 100 it
is indicative of a bad design. 1 time out of 100 maybe you've got
something great with multiple inheritance, but one of the fundamental
philosophies of .NET is to err on the side of safety. Having been a C+
+ programmer for over 10 years, I'm praying multiple inheritance
doesn't ever see the light of day in .NET. Even single inheritance is
abused more often than not, when containment would be a much better
solution.

"Larry Smith" <no_spam@_nospam.com> wrote in message
news:uQGcOrZyHHA.484@TK2MSFTNGP06.phx.gbl...
>>>>> Moreover, it's rarely even used in the C++ world.
>>>
>> That's just... not right.

>> Actually it is. I've worked for many different companies both large and
>> small and almost nobody uses it. I find it very hard to believe this
>> isn't the norm.

Actually, it is. I've worked for many different companies, both large and
small, and almost everybody uses it. I find it very hard to believe this
isn't the norm.

In all honesty, I've used it quite a bit, and people I've worked with (many,
very hardcore OO purests) have also used it quite a bit. Does this mean
people may have overused it? Possibly. But this happens with every
technology.

With .Net, it's especilly frustrating, as your inheritence tree is often
dictated to you by the platform. With my inheritence tree defined (web page,
control, EnterpriseComponet, or whatever), adding my my own behavior means
alot of mindless (and often silly) code duplication. Some of this is
mitigated in .Net 3.5, with Extension Methods, but by no means all of it.

>> It's very frequently used, and is a very powerfull tool to have access
>> to.
>
> I didn't say it wasn't powerful. The mechanics get progressively more
> difficult to work with however as class hiearchies become non-trivial.

The exact same can be said of dozens of technologies:
- Threading technologies.
- Dynamic Code Generation.
- Operator Overloading

Any of these can be, and often are, badly abused.

VB 1-6 didn't have any of them, and the world got along just fine. Tons of
code was written. Obviously they're not needed at all. Clearly this means
even inheritence isn't required, as developers (as Microsoft document from
that era made very, very clear) often screw it up, and Interfaces are a far
superior technology.

>>>> From my own (long) experience in that arena, it makes sense
>>>> conceptually but in practice it's mechanically very difficult to work
>>>> with. I doubt significant improvements can be made on this front.
>>
>> My experience is otherwise. I've used it alot, loved it, had great
>> success with it, and really miss it.
>
> You must have precious little experience dealing with large class
> hierarchies then..

Yeeeea. That's what it is.

> When you factor in issues like virtual base classes, the calling of their
> constructors from the most dervied class (which refutes your claim that
> MI is widely used since very few C++ programmers even know about this),
> the headaches involved with ambiguity (a major pain), etc., then it
> becomes a major deterrent very quickly unless your class hierarchies
> remain trivial.

I'm afraid I don't follow your logic.

The classic MI "Dreaded Diamond Pattern" is certainly on the "don't do this"
list, and need to be worked around with good design. All of the C++ guys
I've worked with have either been aware of this, or quickly been made aware
of it by their peers. I don't see how this changes anything - all of the
advanced technologies have drawbacks that can be, and often are, abused.

For example, threading. Where do you do locking and synchronization? What
thread context is your method running on? Can you access these other classes
or do you need to lock? Are there others calling you from inside a lock - if
so, that database call you're about to make is a really bad idea). Unless
your class hierarchy is trival, these are really hard question. Much harder,
in my opinion, than solving the MI Diamond issues.

For example, anything distributed. Where are you running? In what context?
Is there a network between you and your processor? Should you build chatty
or chunky methods? Can you call this other class at all?

The list goes on....

I'm fine requiring users to take MCP exam 70-666 (Multiple Interitence),
which gives them a key they can put into their compilers to unlock MI.

--
Chris Mullins, MCSD.NET, MCPD:Enterprise, Microsoft C# MVP
http://www.coversant.com/blogs/cmullins

"Larry Smith" <no_spam@_nospam.com> wrote in message
news:uQGcOrZyHHA.484@TK2MSFTNGP06.phx.gbl...
>>>>> Moreover, it's rarely even used in the C++ world.
>>>
>> That's just... not right.

>> Actually it is. I've worked for many different companies both large and
>> small and almost nobody uses it. I find it very hard to believe this
>> isn't the norm.

Actually, it is. I've worked for many different companies, both large and
small, and almost everybody uses it. I find it very hard to believe this
isn't the norm.

In all honesty, I've used it quite a bit, and people I've worked with (many,
very hardcore OO purests) have also used it quite a bit. Does this mean
people may have overused it? Possibly. But this happens with every
technology.

With .Net, it's especilly frustrating, as your inheritence tree is often
dictated to you by the platform. With my inheritence tree defined (web page,
control, EnterpriseComponet, or whatever), adding my my own behavior means
alot of mindless (and often silly) code duplication. Some of this is
mitigated in .Net 3.5, with Extension Methods, but by no means all of it.

>> It's very frequently used, and is a very powerfull tool to have access
>> to.
>
> I didn't say it wasn't powerful. The mechanics get progressively more
> difficult to work with however as class hiearchies become non-trivial.

The exact same can be said of dozens of technologies:
- Threading technologies.
- Dynamic Code Generation.
- Operator Overloading

Any of these can be, and often are, badly abused.

VB 1-6 didn't have any of them, and the world got along just fine. Tons of
code was written. Obviously they're not needed at all. Clearly this means
even inheritence isn't required, as developers (as Microsoft document from
that era made very, very clear) often screw it up, and Interfaces are a far
superior technology.

>>>> From my own (long) experience in that arena, it makes sense
>>>> conceptually but in practice it's mechanically very difficult to work
>>>> with. I doubt significant improvements can be made on this front.
>>
>> My experience is otherwise. I've used it alot, loved it, had great
>> success with it, and really miss it.
>
> You must have precious little experience dealing with large class
> hierarchies then..

Yeeeea. That's what it is.

> When you factor in issues like virtual base classes, the calling of their
> constructors from the most dervied class (which refutes your claim that
> MI is widely used since very few C++ programmers even know about this),
> the headaches involved with ambiguity (a major pain), etc., then it
> becomes a major deterrent very quickly unless your class hierarchies
> remain trivial.

I'm afraid I don't follow your logic.

The classic MI "Dreaded Diamond Pattern" is certainly on the "don't do this"
list, and need to be worked around with good design. All of the C++ guys
I've worked with have either been aware of this, or quickly been made aware
of it by their peers. I don't see how this changes anything - all of the
advanced technologies have drawbacks that can be, and often are, abused.

For example, threading. Where do you do locking and synchronization? What
thread context is your method running on? Can you access these other classes
or do you need to lock? Are there others calling you from inside a lock - if
so, that database call you're about to make is a really bad idea). Unless
your class hierarchy is trival, these are really hard question. Much harder,
in my opinion, than solving the MI Diamond issues.

For example, anything distributed. Where are you running? In what context?
Is there a network between you and your processor? Should you build chatty
or chunky methods? Can you call this other class at all?

The list goes on....

I'm fine requiring users to take MCP exam 70-666 (Multiple Interitence),
which gives them a key they can put into their compilers to unlock MI.

--
Chris Mullins, MCSD.NET, MCPD:Enterprise, Microsoft C# MVP
http://www.coversant.com/blogs/cmullins

[Please do not mail me a copy of your followup]

"Chris Mullins [MVP]" <cmullins@yahoo.com> spake the secret code
<ul2hkCjyHHA.1212@TK2MSFTNGP05.phx.gbl> thusly:

>In all honesty, I've used [multiple inheritance] quite a bit,
>and people I've worked with (many,
>very hardcore OO purests) have also used it quite a bit. Does this mean
>people may have overused it? Possibly. But this happens with every
>technology.

So how do you feel about "Design Patterns" saying you should prefer
aggregation over inheritance?
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.com/~legalize/book/download/index.html>

Legalize Adulthood! <http://blogs.xmission.com/legalize/>

[Please do not mail me a copy of your followup]

"Chris Mullins [MVP]" <cmullins@yahoo.com> spake the secret code
<ul2hkCjyHHA.1212@TK2MSFTNGP05.phx.gbl> thusly:

>In all honesty, I've used [multiple inheritance] quite a bit,
>and people I've worked with (many,
>very hardcore OO purests) have also used it quite a bit. Does this mean
>people may have overused it? Possibly. But this happens with every
>technology.

So how do you feel about "Design Patterns" saying you should prefer
aggregation over inheritance?
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.com/~legalize/book/download/index.html>

Legalize Adulthood! <http://blogs.xmission.com/legalize/>

"Richard" <legalize+jeeves@mail.xmission.com> wrote:

> "Chris Mullins [MVP]" <cmullins@yahoo.com> spake the secret code
>>In all honesty, I've used [multiple inheritance] quite a bit,
>>and people I've worked with (many,
>>very hardcore OO purests) have also used it quite a bit. Does this mean
>>people may have overused it? Possibly. But this happens with every
>>technology.
>
> So how do you feel about "Design Patterns" saying you should prefer
> aggregation over inheritance?

I would feel alot better about aggregation if it were better supported by
the language.

If there was an attribute I could use:

[Aggregatable]
public class Point
{
int x; int y;
}

public class Circle
{
[Aggrigates(type=Single)] Point;
int Radius;
}

This code would:
1 - Automatically create an interface (IPoint) (or even an Anonymous Type)
2 - Automatically turn Circle into "Circle : IPoint"
3 - Automatically wire up "Circle.X" & "Circle.Y"

I would love to see a 1:Many aggrigation attribute as well:
public class VectorField
{
[Aggrigates(type=Collection)] Vector;
}

This would automatically:
1 - Turn VectorField into "VectorField : IList<Vector>"
2 - Implement all the various IList<Vector> code for me

Even more fun would be:
public class TensorField
{
[Aggrigates(type=Dictionary<Vector>)] Tensor;
}

This would automatically:
1 - Turn TensorField into "TensorField:IDictionary<Vector, Tensor>"
2 - Implement all the various IDictionary<Vector,Tensor> code for me

As it sits, aggregation (to me) means, "Write a whole lot of wrapper code to
wire up the various methods". In general though, in .Net I over-use
aggrigation simply becuase with single inheritence, there's no choice.

--
Chris Mullins, MCSD.NET, MCPD:Enterprise, Microsoft C# MVP
http://www.coversant.com/blogs/cmullins