469,286 Members | 2,399 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,286 developers. It's quick & easy.

Alternatives to MI in managed code???

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 Pehrson
mailto:br**@infowest.com
NOSPAM - Include this key in all e-mail correspondence <<38952rglkwdsl>>
Nov 15 '05 #1
10 1118
Bret Pehrson wrote:
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.


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)
Nov 15 '05 #2
> Why not inherit from System.Windows.Form?

As I said:
There is *no way* to add an
interface (ala forms) to that component without changing the base
class itself.

I don't have access to the base class to modify its inheritance.
Frank Oquendo wrote:
Bret Pehrson wrote:
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.


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)


--
Bret Pehrson
mailto:br**@infowest.com
NOSPAM - Include this key in all e-mail correspondence <<38952rglkwdsl>>
Nov 15 '05 #3
Bret Pehrson wrote:
I don't have access to the base class to modify its inheritance.


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)
Nov 15 '05 #4
> If you have access to the derived class, derive a new class from it and
System.Windows.Form.
And that, my friend, is multiple inheritance, which isn't a part of the .NET
subsystem. See my point?

Frank Oquendo wrote:
Bret Pehrson wrote:
I don't have access to the base class to modify its inheritance.


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)


--
Bret Pehrson
mailto:br**@infowest.com
NOSPAM - Include this key in all e-mail correspondence <<38952rglkwdsl>>
Nov 15 '05 #5
Base->inherited->inherited2->blah Inherit one after another.
"Bret Pehrson" <br**@infowest.com> wrote in message
news:40***************@infowest.com...
If you have access to the derived class, derive a new class from it and
System.Windows.Form.
And that, my friend, is multiple inheritance, which isn't a part of the

..NET subsystem. See my point?

Frank Oquendo wrote:

Bret Pehrson wrote:
I don't have access to the base class to modify its inheritance.


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)


--
Bret Pehrson
mailto:br**@infowest.com
NOSPAM - Include this key in all e-mail correspondence <<38952rglkwdsl>>

Nov 15 '05 #6
<di********@discussion.microsoft.com> wrote:
Base->inherited->inherited2->blah Inherit one after another.


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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 15 '05 #7

"Bret Pehrson" <br**@infowest.com> wrote in message
news:40***************@infowest.com...
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.


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
Nov 15 '05 #8

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.

Nov 15 '05 #9
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
"Bret Pehrson" <br**@infowest.com> wrote in message
news:40***************@infowest.com...
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 Pehrson
mailto:br**@infowest.com
NOSPAM - Include this key in all e-mail correspondence <<38952rglkwdsl>>

Nov 15 '05 #10

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.

Nov 15 '05 #11

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

43 posts views Thread by Steven T. Hatton | last post: by
4 posts views Thread by William F. Kinsley | last post: by
21 posts views Thread by Strath-Clyde | last post: by
5 posts views Thread by Chris | last post: by
3 posts views Thread by =?Utf-8?B?bXVzb3NkZXY=?= | last post: by
reply views Thread by suresh191 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.