Strange, but C# does allow multiple inheritance, so long as it's serial

[raylopez99]

Well, contrary to the implication in my 2000 textbook on C# (public
beta version), C# does allow multiple inheritance, so long as it's
serially chained as follows:

class derived02 : derived01
{

}

class derived01 : baseclass01
{
}

class baseclass01
{
}

etc

You just can't inherit from multiple base classes (you have to use an
Interface and simply replicate all base classes, like a virtual base
class in C++)

RL

 

[Marc Gravell]

I'm not sure if this was a reply to a previous post, or what, but what
you have described is not really multiple inheritance as it is
normally understood. Sorry.

Marc

 

[Jon Skeet [C# MVP]]

Well, contrary to the implication in my 2000 textbook on C# (public
beta version), C# does allow multiple inheritance, so long as it's
serially chained as follows:

class derived02 : derived01
{

}

class derived01 : baseclass01
{
}

class baseclass01
{
}

etc

You just can't inherit from multiple base classes (you have to use an
Interface and simply replicate all base classes, like a virtual base
class in C++)

I haven't seen any definition of "multiple inheritance" which would
include that. derived02 is inheriting from derived01, which in turn
inherits from derived01.

 

[Guest]

Ray,
true multiple inheritance would look like this:

class derived01 : base01, base02
{
// where base01 and base02 are both classes that you want derived01 to
derive from, which cannot be done in C#. Sorry.
}

 

[raylopez99]

I'm not sure if this was a reply to a previous post, or what, but what
you have described is not really multiple inheritance as it is
normally understood. Sorry.

Marc

Agreed, but from the english language you would think a chained
inhereitance is also "multiple".

RL

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Agreed, but from the english language you would think a chained
inhereitance is also "multiple".

Would you ?

A computer is a piece of electronics.

A PC is a computer.

But would you say:
a PC is both a computer and a piece of electronics
?

Arne

PS: The described for for inheritance does not have the diamond problem
that multiple inheritance has.

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

Agreed, but from the english language you would think a chained
inhereitance is also "multiple".

RL

Yes, chained inheritance is "multiple" in a way, but that is not what is
meant by multiple inheritance.

Most computer analogies should not be taken that literally.

If you do, inheritance would for example mean that the derived class
would be a completely separate class from the ancestor, just like a son
is a completely separate person from the father.

 

[Jeff Louie]

Ray... I would say that C# supports multiple inheritance of interfaces
(analogous
to pure virtual classes in C++) and single inheritance of an
implementation
chain.

Regards,
Jeff

 

[mahesh kumar]

Directly the c# doesn’t support the multiple inheritance , but multiple interfaces can be allowed…

Like

Public class myTest : IDisplay , IPrint
{



}


But There is one way to implement the multiple inheritance in c#........

Giving you the clue ……. Write the class inside the class ( The internal class ) with that we can implement the multiple inheritance……….

Hope this will help………….You



EggHeadCafe.com - .NET Developer Portal of Choice
http://www.eggheadcafe.com

 

[Guest]

1. How does the book define multiple inheritance, that you are saying can be
contridicted?
2. I would get a more recent book.

 

[raylopez99]

Would you ?

A computer is a piece of electronics.

A PC is a computer.

But would you say:
a PC is both a computer and a piece of electronics
?

Yes, we're programmers after all!

Arne

PS: The described for for inheritance does not have the diamond problem
that multiple inheritance has.

Yes, I know about "diamond inhereitance" problem (ambiguity), and how
C# is supposedly safer. I just wasn't expecting a multiple layer
(n>2) chained inheritance--just my surprise, not anything wrong with
C#.

RL

 

[raylopez99]

1. How does the book define multiple inheritance, that you are saying can be
contridicted?
2. I would get a more recent book.

I'm trying to learn C# using just a yr 2000 book and this Usenet
group--and my C++ background--so far, so good, I am making progress.
I do have a "C# Receipe" book by O'Reilly Press too, which is good.

RL

 

[raylopez99]

But There is one way to implement the multiple inheritance in c#........

Giving you the clue ....... Write the class inside the class ( The internal class ) with that we can implement the multiple inheritance..........

Hope this will help.............You

Ah, genius. You are master! A sort of nested class.

RL

 

[jeffc]

Well, contrary to the implication in my 2000 textbook on C# (public
beta version), C# does allow multiple inheritance, so long as it's
serially chained as follows:

class derived02 : derived01
{

}

class derived01 : baseclass01
{
}

class baseclass01
{
}

Ah, no. That would be like saying "This car comes in multiple colors, as
long as it's black." That's just not multiple inheritance. But you can
come up with a much better example than that for multiple inheritance in C#.

 

[raylopez99]

But you can
come up with a much better example than that for multiple inheritance in C#.

Yes, and as they always say in textbooks, which leaves you guessing,
"that will be left as a programming exercise for the reader".

Personally, I don't like inheritance, unless you need runtime
polymorphism using a base class reference. I don't like even single
inheritance, as it seems to be less flexible than a composition or
nested class. Everything is "HAS-A" but few things are "IS-A" it
seems to me.

BTW an excellent book--that I'm slowly working through--is this book
on class construction: "Design Patterns" by Gamma et al. (forward by
Grady Booch) (1977, 1995). You learn about cool classes like the
"Singleton", which by now is pretty well known, and other such
constructs.

RL

 

[GlennDoten]

Ah, genius. You are master! A sort of nested class.

But that is not OO multiple inheritance!

Yes, it is indeed technically called a nested class, but has nothing to
do with anyone inheriting from that nested class. It's just another
field of that class that it is nested within. See the difference?

If you think about it, a nested class is really just an "external to the
class" (non-nested) class that is "lower down" in the namespace. I'll
try to illustrate with code:

public class A
{
int x;
public class C1 { int y; }
}

public class C2 { int y; }

public class B
{
public C2 C2;
}

public class C : Random, C2
{
}

Class A has a nested class; this may be useful on rare occasions, but
normally the class (see class C2) would be "higher up" in the namespace
so that others can use it as well (see class B). Indeed, classes like B
are created all the time, and it has nothing to do with multiple
inheritance.

If multiple inheritance were allowed then class C could be defined, but
it cannot be because C# does not support multiple inheritance.

 

[Jon Skeet [C# MVP]]

If you think about it, a nested class is really just an "external to the
class" (non-nested) class that is "lower down" in the namespace.

There's one difference which can be really handy (and is completely
unrelated to true multiple inheritance): a nested class has access to
private members in its enclosing class. There are various situations
where that's incredibly useful.

Jon

 

[GlennDoten]

Personally, I don't like inheritance, unless you need runtime
polymorphism using a base class reference. I don't like even single
inheritance, as it seems to be less flexible than a composition or
nested class. Everything is "HAS-A" but few things are "IS-A" it
seems to me.

Yikes! Inheritance is the cat's meow! I create both concrete as well
as abstract base classes all the time. I mean like all the time. I
constantly run up against the pattern where you start designing a class
and realize that there will be multiple "flavors" of the class. It's
base class time. I guess I like them so much mostly because (1) I
absolutely detest writing the same line of code more than once (and
inheritance is one major way that allows me to do that) and (2) it's one
of the basic principles of OO development. And the polymorphism you
mention is an awesome "side" benefit.

Now I could understand you saying that you aren't big on some of the key
OO concepts. That's a perfectly legitimate attitude to have, IMO, and I
could understand that opinion.

This isn't to say I don't use nested classes--well, other classes as
fields within a class--all the time. I do. Maybe once in a blue moon do
I find a reason for a nested class; they don't have much of a use to me
since I pretty much always want to be able to reuse a class I've created
and if today it seems to make sense to be nested into another class.
Whenever I've done that I've more often than noted "backed out" the
nested class so that other classes have access to it just like the
containing class did.

BTW an excellent book--that I'm slowly working through--is this book
on class construction: "Design Patterns" by Gamma et al. (forward by
Grady Booch) (1977, 1995). You learn about cool classes like the
"Singleton", which by now is pretty well known, and other such
constructs.

Yes, the Gang of Four should be read by any person wanting to do OO. The
cool lingo that all the kids use for things like a singleton these days
are "patterns," don't-cha know?

 

[Jon Skeet [C# MVP]]

Yikes! Inheritance is the cat's meow! I create both concrete as well
as abstract base classes all the time. I mean like all the time.

That suggests to me that you may be *overusing* them. As the GoF
suggests, "favour composition over inheritance".

Here's my take on why inheritance can be painful:

http://msmvps.com/blogs/jon.skeet/archive/2006/03/04/inheritancetax.aspx

That's not to say it's not useful in its place, but it can easily be
overused.

Jon

 

[GlennDoten]

That suggests to me that you may be *overusing* them. As the GoF
suggests, "favour composition over inheritance".

I don't believe that I am, but understand your point. And I may have
gotten carried away in my description. I didn't mean to say that I use
them indiscriminately, I just meant that inheritance is incredibly
useful and to shun it--particularly for unspecified reason--is a little
bit crazy in the OO world.

Here's my take on why inheritance can be painful:

http://msmvps.com/blogs/jon.skeet/archive/2006/03/04/inheritancetax.aspx

That's not to say it's not useful in its place, but it can easily be
overused.

Yes, I understand what you are saying and agree. What I've seen at the
places I've worked though is that inheritance is highly underused. A
shame, really. Might's well just go back to VB (pre-.NET VB, that is).