G
Guest
Hi ,
Can Anyone explain me exactly why multiple inheritance not used in java and c#
thanks,
Mahesh
Can Anyone explain me exactly why multiple inheritance not used in java and c#
thanks,
Mahesh
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
J
Jon Skeet [C# MVP]
MAHESH MANDHARE said:Can Anyone explain me exactly why multiple inheritance not used in java and c#
Basically because they introduce additional complexity into the
language which can then mean additional complexity in the code (whether
it means the code being more obviously complicated, or just harder to
understand at a glance).
It was also considered that multiple inheritance of implementation is
rarely very beneficial. Note that there is still multiple inheritance
of interface in both .NET and Java.
Never having used multiple inheritance of implementation myself, I
can't comment on how much of a loss it is, but I can't say I've often
thought "ooh, I wish I could derive from both of these classes" in my
code.
M
Mark Broadbent
http://blogs.msdn.com/csharpfaq/archive/2004/03/07/85562.aspx
My personal opinion (for what it is worth!) is that it is a real shame not
to include this (regardless of all the potential pitfalls). Having heard a
speech by Anders a couple of years back, I got the impression that he really
didn't like it. But I guess that there has been only a few occasions that I
thought that I really wanted to be able to do this ...but maybe my approach
is different because I know I can't.
Br,
Mark.
My personal opinion (for what it is worth!) is that it is a real shame not
to include this (regardless of all the potential pitfalls). Having heard a
speech by Anders a couple of years back, I got the impression that he really
didn't like it. But I guess that there has been only a few occasions that I
thought that I really wanted to be able to do this ...but maybe my approach
is different because I know I can't.
Br,
Mark.
C
cody
There is a proposal from Anders Hejlsberg to add support for a default
implementation to interfaces to C#, this is something like a limited support
for MI but sounds useful.
implementation to interfaces to C#, this is something like a limited support
for MI but sounds useful.
R
Radek Cerny
I agree wholeheartedly. I had MI in a previous world (Gupta/Centura 4GL)
and I miss it dearly. Mind you I think that all in all, c# is pretty damn
good, but I can make several real cases where MI is the correct design/model
and would save a fair amount of duplication. I have pretty much given up
hope on ever seeing it in the CLR tho.
Radek
and I miss it dearly. Mind you I think that all in all, c# is pretty damn
good, but I can make several real cases where MI is the correct design/model
and would save a fair amount of duplication. I have pretty much given up
hope on ever seeing it in the CLR tho.
Radek
Mark Broadbent said:http://blogs.msdn.com/csharpfaq/archive/2004/03/07/85562.aspx
My personal opinion (for what it is worth!) is that it is a real shame not
to include this (regardless of all the potential pitfalls). Having heard a
speech by Anders a couple of years back, I got the impression that he
really didn't like it. But I guess that there has been only a few
occasions that I thought that I really wanted to be able to do this ...but
maybe my approach is different because I know I can't.
Br,
Mark.
G
Guest
Complexity can not be the reason for not adding MI,MI can depict Real world
model
when class derives from two or more parents,we can use interfaces for that I
aggree but Language Lacks one of the object oriented paradigm
Mahesh
--
Have A Good Day,
Mahesh,
(e-mail address removed)
model
when class derives from two or more parents,we can use interfaces for that I
aggree but Language Lacks one of the object oriented paradigm
Mahesh
--
Have A Good Day,
Mahesh,
(e-mail address removed)
J
Jon Skeet [C# MVP]
MAHESH MANDHARE said:Complexity can not be the reason for not adding MI
It can be the stated reason. Personally I'm quite happy to have a
simpler language at the cost of MI, but I realise it's a trade-off not
everyone's happier with.
MI can depict Real world model when class derives from two or more
parents,we can use interfaces for that I aggree but Language Lacks
one of the object oriented paradigm
It's not one of the pillars of object orientation as far as I'm
concerned, personally...
G
Guest
hi Radek,
ya i think there must be some genune reason or problems with using MI .
I just wanted to know that.
can you describe real cases where MI is the correct design/model
and would save a fair amount of duplication.
Mahesh
--
Have A Good Day,
Mahesh,
(e-mail address removed)
ya i think there must be some genune reason or problems with using MI .
I just wanted to know that.
can you describe real cases where MI is the correct design/model
and would save a fair amount of duplication.
Mahesh
--
Have A Good Day,
Mahesh,
(e-mail address removed)
Radek Cerny said:I agree wholeheartedly. I had MI in a previous world (Gupta/Centura 4GL)
and I miss it dearly. Mind you I think that all in all, c# is pretty damn
good, but I can make several real cases where MI is the correct design/model
and would save a fair amount of duplication. I have pretty much given up
hope on ever seeing it in the CLR tho.
Radek
W
Wiebe Tijsma
I'd be interested in wich cases, I've been thinking a lot about that...
(not out of scepticism, but out of ... em interest & learning possibilities)
Care to enlighten me?
Thanks,
Wiebe
(not out of scepticism, but out of ... em interest & learning possibilities)
Care to enlighten me?
Thanks,
Wiebe
Radek said:I agree wholeheartedly. I had MI in a previous world (Gupta/Centura 4GL)
and I miss it dearly. Mind you I think that all in all, c# is pretty damn
good, but I can make several real cases where MI is the correct design/model
and would save a fair amount of duplication. I have pretty much given up
hope on ever seeing it in the CLR tho.
Radek
R
Radek Cerny
In my architecture, I keep 100% separation of business functionality from
presentation layer (Web Services connect a rich,thin client to functional
server objects). So I have two separate cases. Server-side, I have more
control over, as I do not use Datasets or such - my objects are built from
the ground up.
However, on the client, I must provide all controls that are capable of
talking my specific Web Service schema to the server, but I must inherit
from the standard WinForms controls. I have no choice but to replicate code
in a checkbox, textbox, radio button class etc. If I had MI, I would have
an abstract class that understood my schema, and all the window classes
would inherit from that as well as the .NET supplied standard Windows
classes. For now, I can only implement an interface, but there is much code
that is identical across controls.
Server-side, I would still like MI, but learned to live without it.
Philosophically, I can not understand those who do not appreciate MI; used
correctly, you can normalise your code base like you would normalise your
database.
Radek
presentation layer (Web Services connect a rich,thin client to functional
server objects). So I have two separate cases. Server-side, I have more
control over, as I do not use Datasets or such - my objects are built from
the ground up.
However, on the client, I must provide all controls that are capable of
talking my specific Web Service schema to the server, but I must inherit
from the standard WinForms controls. I have no choice but to replicate code
in a checkbox, textbox, radio button class etc. If I had MI, I would have
an abstract class that understood my schema, and all the window classes
would inherit from that as well as the .NET supplied standard Windows
classes. For now, I can only implement an interface, but there is much code
that is identical across controls.
Server-side, I would still like MI, but learned to live without it.
Philosophically, I can not understand those who do not appreciate MI; used
correctly, you can normalise your code base like you would normalise your
database.
Radek
C
cody
why not making a class for cummunicating with the server and instantiating
it in each control?
class ServerTalker
{
public ServerTalker(Control c){}
}
it in each control?
class ServerTalker
{
public ServerTalker(Control c){}
}
B
Bruce Wood
The classic problem with multiple inheritance, which Anders mentioned
in his whiteboard talk, is the diamond problem, created by this
scenario:
public class A { ... }
public class B : A { ... }
public class C : A { ... }
public class D : B, C { ... }
If classes B and C both override the same virtual member of A, which
member do you choose in D? B's override or C's override? This is, I
think, the "added complexity" that people are talking about here.
My impression from Anders' whiteboard talk is that you so rarely want
full-blown multiple inheritance that it's not really worth the hassle
it introduces. Everything you add to a language makes it more
complicated to some degree, and so you have to weigh potential benefits
versus added complexity. I think that Anders Hejlsberg is a minimalist
at heart, and prefers to leave features out of a language unless
there's a compelling reason to include them.
in his whiteboard talk, is the diamond problem, created by this
scenario:
public class A { ... }
public class B : A { ... }
public class C : A { ... }
public class D : B, C { ... }
If classes B and C both override the same virtual member of A, which
member do you choose in D? B's override or C's override? This is, I
think, the "added complexity" that people are talking about here.
My impression from Anders' whiteboard talk is that you so rarely want
full-blown multiple inheritance that it's not really worth the hassle
it introduces. Everything you add to a language makes it more
complicated to some degree, and so you have to weigh potential benefits
versus added complexity. I think that Anders Hejlsberg is a minimalist
at heart, and prefers to leave features out of a language unless
there's a compelling reason to include them.
W
Wiebe Tijsma
Sounds like you're tightly coupling components directly to your model,
maybe you just need to apply the MVC (Model-View Controller) pattern.
You can mimic MI by delegating your interface to a class implementing
the same interface right?
It does require you to redeclare all implementing methods indeed, wich
is a pain if your interface is fairly complex and need to implement it
on many classes.
Antoher option is to declare 2 interfaces/base class, and have your
classes work with both. like the IXPathNavigable and XPathNavigator,
where the declaring interface only consists of 1 method that retrieves
the more complex base class instance:
interface IXPathNavigable {
XPathNavigator CreateNavigator();
}
like this:
interface IMyInterface {
... many methods implementation ...
}
interface IMyInterfaceSource {
IMyInterface GetMyInterface()
}
public class MyClass : IMyInterface, IMyInterfaceSource {
/* many methods implementation */
IMyInterface IMyInterfaceSource.GetMyInterface(){
return this;
}
}
// Your inherited components only need to implement IMyInterfaceSource,
// wich could be relatively easy with 4 lines of code:
public class MyCheckBox : CheckBox, IMyInterfaceSource {
private IMyInterface implementation = new MyClass();
IMyInterface IMyInterfaceSource.GetMyInterface(){
return implementation;
}
}
[ I do believe interfaces should be kept simple though, and if it
requires a lot of methods, don't use interfaces but abstract base classes ]
sometimes I miss some delphi functionality, where you can delegate the
entire interface to a property of the instance. Explanation:
http://www.netindustry.nl/blog/2005/04/wheres-in-c.html
Hmm maybe I should write an article about it, any suggestions? ;-)
About the table normalization, isn't a table layout much more limited
than MI? I don't even use databases at the moment that use table
inheritance at all, let alone multiple table inheritance, wich one do
you use?
Wiebe
maybe you just need to apply the MVC (Model-View Controller) pattern.
You can mimic MI by delegating your interface to a class implementing
the same interface right?
It does require you to redeclare all implementing methods indeed, wich
is a pain if your interface is fairly complex and need to implement it
on many classes.
Antoher option is to declare 2 interfaces/base class, and have your
classes work with both. like the IXPathNavigable and XPathNavigator,
where the declaring interface only consists of 1 method that retrieves
the more complex base class instance:
interface IXPathNavigable {
XPathNavigator CreateNavigator();
}
like this:
interface IMyInterface {
... many methods implementation ...
}
interface IMyInterfaceSource {
IMyInterface GetMyInterface()
}
public class MyClass : IMyInterface, IMyInterfaceSource {
/* many methods implementation */
IMyInterface IMyInterfaceSource.GetMyInterface(){
return this;
}
}
// Your inherited components only need to implement IMyInterfaceSource,
// wich could be relatively easy with 4 lines of code:
public class MyCheckBox : CheckBox, IMyInterfaceSource {
private IMyInterface implementation = new MyClass();
IMyInterface IMyInterfaceSource.GetMyInterface(){
return implementation;
}
}
[ I do believe interfaces should be kept simple though, and if it
requires a lot of methods, don't use interfaces but abstract base classes ]
sometimes I miss some delphi functionality, where you can delegate the
entire interface to a property of the instance. Explanation:
http://www.netindustry.nl/blog/2005/04/wheres-in-c.html
Hmm maybe I should write an article about it, any suggestions? ;-)
About the table normalization, isn't a table layout much more limited
than MI? I don't even use databases at the moment that use table
inheritance at all, let alone multiple table inheritance, wich one do
you use?
Wiebe
R
Radek Cerny
That would work, but its as much work to intercept the events and pass on
the relevant data. And it does not read/feel as good.
the relevant data. And it does not read/feel as good.
R
Radek Cerny
Its not really tight coupling. I have a an appserver that houses stateful
user sessions that house by business objects. These objects have Fields and
Methods, and an inbuilt O/R mapping layer. The user interface is simply a
"mirror" of the innards of the business objects. So if the UI changes a
Field, it tells the business object, via a WebService, eg
<Field id="FirstName" value="Radek"/>. The server keeps all internal
changes and publishes any other value changes, and the UI is responsible for
displaying the results. So each client widget, eg TextBox, CheckBox etc
must know what Field it is bound to (or method if its a Button), and
sufficient logic to compose a reasonable request to the server (you can
change more than value, and NULLs always complicate things etc). I would
love to encapsulate this in a class (which I have in the Gupta language) and
simply inherit from both the Windows Control type and my class. At worst, I
would have to tie change events together and invoke a method. The member
variables, such as the Field I am bound to are necessarily repeated for each
Windows control type, and that offends me. There is no such design/code
duplication on the server code.
Radek
user sessions that house by business objects. These objects have Fields and
Methods, and an inbuilt O/R mapping layer. The user interface is simply a
"mirror" of the innards of the business objects. So if the UI changes a
Field, it tells the business object, via a WebService, eg
<Field id="FirstName" value="Radek"/>. The server keeps all internal
changes and publishes any other value changes, and the UI is responsible for
displaying the results. So each client widget, eg TextBox, CheckBox etc
must know what Field it is bound to (or method if its a Button), and
sufficient logic to compose a reasonable request to the server (you can
change more than value, and NULLs always complicate things etc). I would
love to encapsulate this in a class (which I have in the Gupta language) and
simply inherit from both the Windows Control type and my class. At worst, I
would have to tie change events together and invoke a method. The member
variables, such as the Field I am bound to are necessarily repeated for each
Windows control type, and that offends me. There is no such design/code
duplication on the server code.
Radek
Wiebe Tijsma said:Sounds like you're tightly coupling components directly to your model,
maybe you just need to apply the MVC (Model-View Controller) pattern.
You can mimic MI by delegating your interface to a class implementing the
same interface right?
It does require you to redeclare all implementing methods indeed, wich is
a pain if your interface is fairly complex and need to implement it on
many classes.
Antoher option is to declare 2 interfaces/base class, and have your
classes work with both. like the IXPathNavigable and XPathNavigator, where
the declaring interface only consists of 1 method that retrieves the more
complex base class instance:
interface IXPathNavigable {
XPathNavigator CreateNavigator();
}
like this:
interface IMyInterface {
... many methods implementation ...
}
interface IMyInterfaceSource {
IMyInterface GetMyInterface()
}
public class MyClass : IMyInterface, IMyInterfaceSource {
/* many methods implementation */
IMyInterface IMyInterfaceSource.GetMyInterface(){
return this;
}
}
// Your inherited components only need to implement IMyInterfaceSource, //
wich could be relatively easy with 4 lines of code:
public class MyCheckBox : CheckBox, IMyInterfaceSource {
private IMyInterface implementation = new MyClass();
IMyInterface IMyInterfaceSource.GetMyInterface(){
return implementation;
}
}
[ I do believe interfaces should be kept simple though, and if it requires
a lot of methods, don't use interfaces but abstract base classes ]
sometimes I miss some delphi functionality, where you can delegate the
entire interface to a property of the instance. Explanation:
http://www.netindustry.nl/blog/2005/04/wheres-in-c.html
Hmm maybe I should write an article about it, any suggestions? ;-)
About the table normalization, isn't a table layout much more limited than
MI? I don't even use databases at the moment that use table inheritance at
all, let alone multiple table inheritance, wich one do you use?
Wiebe
Radek said:In my architecture, I keep 100% separation of business functionality from
presentation layer (Web Services connect a rich,thin client to functional
server objects). So I have two separate cases. Server-side, I have more
control over, as I do not use Datasets or such - my objects are built
from the ground up.
However, on the client, I must provide all controls that are capable of
talking my specific Web Service schema to the server, but I must inherit
from the standard WinForms controls. I have no choice but to replicate
code in a checkbox, textbox, radio button class etc. If I had MI, I
would have an abstract class that understood my schema, and all the
window classes would inherit from that as well as the .NET supplied
standard Windows classes. For now, I can only implement an interface,
but there is much code that is identical across controls.
Server-side, I would still like MI, but learned to live without it.
Philosophically, I can not understand those who do not appreciate MI;
used correctly, you can normalise your code base like you would normalise
your database.
Radek
G
Guest
That would be fantastic!
One of my bug-bears with C# is that there is no way to provide a stock
implementation of an interface. ATL makes great use of that ability with the
I*Impl templates, and it would be great to be able to do a similar thing in
C#.
Sure, it isn't absolutely necessary, but the alternative is the old
cut-and-paste methodology which I despise.
Aaron.
One of my bug-bears with C# is that there is no way to provide a stock
implementation of an interface. ATL makes great use of that ability with the
I*Impl templates, and it would be great to be able to do a similar thing in
C#.
Sure, it isn't absolutely necessary, but the alternative is the old
cut-and-paste methodology which I despise.
Aaron.
cody said:There is a proposal from Anders Hejlsberg to add support for a default
implementation to interfaces to C#, this is something like a limited support
for MI but sounds useful.
G
Guest
hi Bruce ,
we can specify that this D's method is derived from b or c.
In the Languages like c++ this kind of functionality is there then why not
in c#
we can specify that this D's method is derived from b or c.
In the Languages like c++ this kind of functionality is there then why not
in c#
R
Radek Cerny
I would be happy with an MI implementation that would disallow that pattern,
although as Mahesh pointed out, there are ways around it if allowed.
Unfortunately, having been brought up in an MI OO world, I think and design
in MI, but in the end have to settle for an SI implementation.
although as Mahesh pointed out, there are ways around it if allowed.
Unfortunately, having been brought up in an MI OO world, I think and design
in MI, but in the end have to settle for an SI implementation.
G
Guest
MI is a feature of OO. Without MI, you couldn’t represent real world objects
as they are in the real world… When you’re doing your design, you model
things as they are in the real world, and therefore creating an accurate
representation of the things within your system. However, because not all
the features of OO are supported within the language (C#, Java…) you need to
make implementation decision within your design… If the thing in the system
is derived from several other things, then surely the language should support
that? Good design will mean that MI only happens where it actually happens
in the real world.
And anyway, shouldn’t it be up to the designer at design time how
complicated a part of a system is, why should the language inhibit the
ability to create systems which represent the design? Bad design brings many
problems, coupling cohesion and MI problems… Good design prevails, let
people have MI.
as they are in the real world… When you’re doing your design, you model
things as they are in the real world, and therefore creating an accurate
representation of the things within your system. However, because not all
the features of OO are supported within the language (C#, Java…) you need to
make implementation decision within your design… If the thing in the system
is derived from several other things, then surely the language should support
that? Good design will mean that MI only happens where it actually happens
in the real world.
And anyway, shouldn’t it be up to the designer at design time how
complicated a part of a system is, why should the language inhibit the
ability to create systems which represent the design? Bad design brings many
problems, coupling cohesion and MI problems… Good design prevails, let
people have MI.
J
Jon Skeet [C# MVP]
Tom said:MI is a feature of OO.
It's a feature of *some* OO languages, and those who are fans of those
languages tend to decide to define it as a feature of OO itself.
Without MI, you couldn?t represent real world objects
as they are in the real world? When you?re doing your design, you model
things as they are in the real world, and therefore creating an accurate
representation of the things within your system.
My experience is that trying to make things just like they are in the
real world is a recipe for disaster in OO. I suspect we'll just have to
agree to disagree on this though.
However, because not all
the features of OO are supported within the language (C#, Java?) you need to
make implementation decision within your design? If the thing in the system
is derived from several other things, then surely the language should support
that? Good design will mean that MI only happens where it actually happens
in the real world.
And anyway, shouldn?t it be up to the designer at design time how
complicated a part of a system is, why should the language inhibit the
ability to create systems which represent the design? Bad design brings many
problems, coupling cohesion and MI problems? Good design prevails, let
people have MI.
The same argument can be (and has been) made about garbage collection -
why should we be "babied" in terms of memory allocation? We're smart
developers, let us handle it.
Blugh. Give me a simple language with garbage collection over a complex
language without it any day.
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.