Alternatives to MI in managed code???

  • Thread starter Thread starter Bret Pehrson
  • Start date Start date
B

Bret Pehrson

Since managed code (C++/C#/etc.) doesn't support multiple inheritance, does
anyone have a suitable work-around? To me, this is a *serious* limitation of
the .NET subsystem.

I'm aware of *interfaces*, but they are for the *USER* of the class, not the
*IMPLEMENTOR*. I'm also aware of adding multiple classes to a class and then
creating wrappers (more of a HAS-A implementation than IS-A), but that is
tedious and again is more for the class user and doesn't support polymorphism.

Here is an example:

Suppose I have a non-trivial class that has no interface (it is purely a
functional component). There is *no way* to add an interface (ala forms) to
that component without changing the base class itself.
 
Bret said:
Suppose I have a non-trivial class that has no interface (it is
purely a functional component). There is *no way* to add an
interface (ala forms) to that component without changing the base
class itself.
Click to expand...

Why not inherit from System.Windows.Form?

--
There are 10 kinds of people. Those who understand binary and those who
don't.

http://code.acadx.com
(Pull the pin to reply)
 
Why not inherit from System.Windows.Form?

As I said:

I don't have access to the base class to modify its inheritance.
 
Bret said:
I don't have access to the base class to modify its inheritance.
Click to expand...

If you have access to the derived class, derive a new class from it and
System.Windows.Form.

--
There are 10 kinds of people. Those who understand binary and those who
don't.

http://code.acadx.com
(Pull the pin to reply)
 
If you have access to the derived class, derive a new class from it and
System.Windows.Form.
Click to expand...

And that, my friend, is multiple inheritance, which isn't a part of the .NET
subsystem. See my point?
 
Base->inherited->inherited2->blah Inherit one after another.
Click to expand...

That doesn't help Bret. There is no way of taking two unrelated,
unmodifiable base classes (as he has) and creating one derived class
which inherits, directly or indirectly, from both of them.
 
Hi Bret,

Thank you for posting in the community!

Based on my understanding, you want to make your non-UI component to have
UI.
====================================================
..Net does not support multi-inheritance, so you can not inherit from other
control class to include UI function.

I agree with Sami that the simplest way to do is using composition. You
only need to create a UI object in your component.

You also may override a UI class and implement your component function in
the child class.

====================================================
Please apply my suggestion above and let me know if it helps resolve your
problem.

Thank you for your patience and cooperation. If you have any questions or
concerns, please feel free to post it in the group. I am standing by to be
of assistance.
Have a nice day!!

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
 
Bret Pehrson said:
Since managed code (C++/C#/etc.) doesn't support multiple inheritance, does
anyone have a suitable work-around? To me, this is a *serious* limitation of
the .NET subsystem.

I'm aware of *interfaces*, but they are for the *USER* of the class, not the
*IMPLEMENTOR*. I'm also aware of adding multiple classes to a class and then
creating wrappers (more of a HAS-A implementation than IS-A), but that is
tedious and again is more for the class user and doesn't support polymorphism.

Here is an example:

Suppose I have a non-trivial class that has no interface (it is purely a
functional component). There is *no way* to add an interface (ala forms) to
that component without changing the base class itself.
Click to expand...

Implementation inheritance (i.e., inheriting only for the purposes of
reusing an implementation) is often questionable. You should inherit only if
there really is an 'is-a' relation between the classes, IMO.

I think the way you should go about this is to use composition. This is
admittedly more coding - you'll need to manually delegate method calls from
the containing class to the containee - but it keeps the design cleaner. In
your case, you might want to consider creating a Form class that has the
functional class as its member. The Form can then expose its own interface
and implement it in terms of the functional class.

Sami
 
I've often wanted this feature for building custom asp.net server controls.
When I need to make a common modification to 23 of the standard controls
included in the vs.net toolbox (framework itself) I found myself
copy-and-pasting the same code into 23 inherited classes that represent each
control. I didn't like that because if my original code had a typo or
defect, I had to go and re-copy-and-paste all those others and it got to be
so time consuming that I actually found it much faster and easier to create
my own base class that inherits webcontrol and then all of the 23 custom
control inherit that. Then, I re-implement all of the 23 controls in
ASP.NET from scratch. My productivity is much higher now.

I could not find a way to both inherit from the original control and from my
common base class which would have only contained the addition "common"
functionality (not inherited from webcontrol) for all 23 classes. I don't
want to use the "composition" technique, either. Because that wouldn't have
solved my problem without all the code duplication and there is less
productivity, IME (in my experience).

So I'm highly productive now but have reimplemented the controls from
scratch (which many may argue is less efficient because I'm not benefitting
from other people's work). Let them argue. They aren't the ones losing
productivity over this issue. The button control is a prime example of why
I want to create it from scratch, it hardcode the type as a submit and
provides no way to override it without inserting an additional attribute of
type=button and so, to provide a way to specify what type of button it is, I
had to create it from scratch. So I couldn't inherit from the base class
anyway, and reuse it, not without having this problem.

They say that MI is evil. Maybe many in the C++ world don't understand it
and they abuse it. But I've never had problems with it. Again, with
Eiffel, it is very well implemented and hardly causes problems. So I don't
see why it would be a problem in the CLR except that "common-denominator"
programmers will likely abuse it. Well, mixed unsafe code in C# can be
abused also and that didn't stop them from putting it there as are many
other features that can be abused but are still there and aren't being
abused. In the end, the prevailing argument is that it would hurt the
performance of the JIT process. I can buy that, but it can always be
optimized.

Microsoft has many of the smartest people in the world working there, I find
it hard to believe that can't find a good solution for this problem but,
Anders, will probly never allow it and that it the true reason. When the
designer is inherently biased against a feature, there is a good chance it
won't ever be more than considered and always remain and -10 in the hole
(they use a point system for determining what features to add to the
language and always starts at -10 and works its way up or not).

Thanks,
Shawn
 
Hi Bret,

Do you still have any concern?
If you still have anything unclear, please feel free to post, we will help
you. Thanks

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
 
Back
Top