how to do a multiple inheritance - like

[Gaetan]

hi

i have 2 classes A1 and A2 implementing a problem with 2 different
ways
i also have 2 other classes X1 and X2 implementing an other problem

i need classes that provide A1+X1 methods, A1+X2, A2+X1 and A2+X2:

interface A
class A1 implements A
class A2 implements A
interface X
class X1 implements X
class X2 implements X

(note: each class add custom public methods that cannot be in the
interface.

class A1X1 inherits A1, inherits X1
class A1X2 inherits A1, inherits X2
class A2X1 inherits A2, inherits X1
class A2X2 inherits A2, inherits X2

In pure C++ it was realy simple, but in C# (and VB) I cannot do that!
and i cannot use C++ in my project.

The only way to have multiple inheritance is to use interface... but
where is the interest to write 4 times the same code in
implementation!!!?

I like to use classes to store function to not write them sevral
times, so i don t think using inheritance with interfaces is a good
idea (because interface doesn t containt code).
I'm used to have interfaces in C++ on top of my hierarchy and have
multiple inheritance between lower classes and i cannot do this now !
I know it s the same problem in java so there should be a way (a
receipe?) to avoid multiple inheritance.

[Frans Bouma [C# MVP]]

Gaetan wrote:

hi

i have 2 classes A1 and A2 implementing a problem with 2 different
ways
i also have 2 other classes X1 and X2 implementing an other problem

i need classes that provide A1+X1 methods, A1+X2, A2+X1 and A2+X2:

interface A
class A1 implements A
class A2 implements A
interface X
class X1 implements X
class X2 implements X

(note: each class add custom public methods that cannot be in the
interface.

class A1X1 inherits A1, inherits X1
class A1X2 inherits A1, inherits X2
class A2X1 inherits A2, inherits X1
class A2X2 inherits A2, inherits X2

In pure C++ it was realy simple, but in C# (and VB) I cannot do that!
and i cannot use C++ in my project.

The only way to have multiple inheritance is to use interface... but
where is the interest to write 4 times the same code in
implementation!!!?

I like to use classes to store function to not write them sevral
times, so i don t think using inheritance with interfaces is a good
idea (because interface doesn t containt code).
I'm used to have interfaces in C++ on top of my hierarchy and have
multiple inheritance between lower classes and i cannot do this now !
I know it s the same problem in java so there should be a way (a
receipe?) to avoid multiple inheritance.

What you experience is indeed a thing that some people consider a 'flaw' in
..NET: lack of multiple implementation inheritance. (I'm one of them). You can
somewhat work around this using aggregation. In A1X1, you inherit from A1 and
implement X again, but you also enclose an instance of X1, so your X
implementation is a wrapper (stub) which simply calls X1 methods. With the
interface stubber in VS.NET 2003, not that hard to do, and you save yourself
double implementations of the real logic. Not that great, but workable.

FB

--
Get LLBLGen Pro, the new O/R mapper for .NET: http://www.llblgen.com
My .NET Blog: http://weblogs.asp.net/fbouma
Microsoft C# MVP

[Bjorn Abelli]

"Gaetan" wrote...

i have 2 classes A1 and A2 implementing a
problem with 2 different ways
i also have 2 other classes X1 and X2 implementing
an other problem

i need classes that provide A1+X1 methods,
A1+X2, A2+X1 and A2+X2:

interface A
class A1 implements A
class A2 implements A

interface X
class X1 implements X
class X2 implements X

(note: each class add custom public methods
that cannot be in the interface.

class A1X1 inherits A1, inherits X1
class A1X2 inherits A1, inherits X2
class A2X1 inherits A2, inherits X1
class A2X2 inherits A2, inherits X2
The only way to have multiple inheritance is to use
interface... but where is the interest to write 4
times the same code in implementation!!!?
You don't have to write the implementation more than once.
I know it s the same problem in java so there should
be a way (a receipe?) to avoid multiple inheritance.

A common approach is to use composition:

class A1X1 implements A, X
{
private A1 a1...
private X1 x1...

// and the "implementation" in A1X1 only passes
// the calls to the included instances
}

....or:

class A1X1 extends A1 implements X
{
private X1 x1...

// and the "implementation" for X only passes
// the calls to the instance above
}

....etc.

There are many more ways to achieve this...

The pattern you described above also suggests that you possibly could
benefit from some Factory-pattern, but that actually depends on how these
classes actually will be used.

// Bjorn A

[Niki Estner]

"Gaetan" <ga****@xeberon.net> wrote in
news:97**************************@posting.google.c om...

...
I know it s the same problem in java so there should be a way (a
receipe?) to avoid multiple inheritance.

Yes: It's called "software design".
If you need the functionality of two different classes, create two instances
of those classes and call methods these. If they need to communicate with
each other to fullfil their job, create an interface to define what
communication may happen.
In 99.9% of the cases this approach will produce better code than using
multiple inheritance.
If you think you have a case out of those other 0.1% - please post it!

Niki

[Frans Bouma [C# MVP]]

Niki Estner wrote:

"Gaetan" <ga****@xeberon.net> wrote in
news:97**************************@posting.google.c om...

...
I know it s the same problem in java so there should be a way (a
receipe?) to avoid multiple inheritance.

Yes: It's called "software design".
If you need the functionality of two different classes, create two instances
of those classes and call methods these. If they need to communicate with
each other to fullfil their job, create an interface to define what
communication may happen.
In 99.9% of the cases this approach will produce better code than using
multiple inheritance.
If you think you have a case out of those other 0.1% - please post it!

I can think of a lot of cases :) For example every I*able interface
describes behaviour. If you could implement an abstract implementation of
that interface which is written using for example the strategy pattern, you
can create classes which should support a given behaviour very fast by
multiple inheriting from these abstract implementations, only filling in the
blanks :)

In .NET there is another example: a class which is a collection class and
which also should support COM+. It therefore has to inherit from
ServicedComponent, and therefore automatically requires aggregates for the
collection logic, not a lot of fun :)

FB
--
Get LLBLGen Pro, the new O/R mapper for .NET: http://www.llblgen.com
My .NET Blog: http://weblogs.asp.net/fbouma
Microsoft C# MVP

[Niki Estner]

"Frans Bouma [C# MVP]" <pe******************@xs4all.nl> wrote in
news:xn***************@msnews.microsoft.com...

...
I can think of a lot of cases :) For example every I*able interface
describes behaviour. If you could implement an abstract implementation of
that interface which is written using for example the strategy pattern, you can create classes which should support a given behaviour very fast by
multiple inheriting from these abstract implementations, only filling in the blanks :)
I agree, abstract default-implementations of interfaces are nice, but why do
you need multiple inheritance for that?
Usually you have to implement an interface because some method of some other
class requires a reference to that interface - but you can implement that
interface anywhere, you don't have to create unneccessarey complex (and
hardly reusable) classes that implement two (or more) unrelated interfaces.

And, btw: C#'s event-keyword is far better than anything C++ has to offer
for "quickly filling in the blanks".
In .NET there is another example: a class which is a collection class and
which also should support COM+. It therefore has to inherit from
ServicedComponent, and therefore automatically requires aggregates for the
collection logic, not a lot of fun :)

I'm not sure if I got that example:
Using multiple inheritance, you would create one class derved from a
ServicedComponent and a collection class. Then you'd write an implementation
for every abstract method of ServicedComponent which calls a method
inherited from the collection class.
Ok, without MI, you do the same, but you call methods of a member instead of
an ancestor.
I don't see the difference?

Niki

[Aquila Deus]

Niki Estner wrote:

"Gaetan" <ga****@xeberon.net> wrote in
news:97**************************@posting.google.c om...

...
I know it s the same problem in java so there should be a way (a
receipe?) to avoid multiple inheritance.
Yes: It's called "software design".
If you need the functionality of two different classes, create two

instances of those classes and call methods these. If they need to communicate with each other to fullfil their job, create an interface to define what
communication may happen.
In 99.9% of the cases this approach will produce better code than using multiple inheritance.
If you think you have a case out of those other 0.1% - please post

it!

I have one - my GUI design:

There are two kinds of GUI controls - Basic controls decide what to do,
and theme controls decide how to do. Each UI *control* (seen by
end-user) actually consists of a basic control and a theme control.

For example, a Button may consist of a BasicButton and a
MacStyleButton. The "Button" itself is an interface. And the real class
(implementation) created is MacStyleButton.

The MacStyleButton must inherit both of (abstract) BasicButton and
MacStyleControl. BasicButton can't just be an interface because it also
defines some common tasks, such as DoClick, Text (property), etc.

And for the theme, traditional theme engines decide only how controls
are rendered, so that they could use something like a ThemeEngine
class, providing RenderButton, RenderMenu, etc. But what if different
themes have different behaviors? For example, selecting a menu item in
windows and that in CDE: In windows you click menu, submenu, then
menuitem; but in CDE you press the button - and don't release, until
the mouse pointer moves to the item you want (submenus are expanded
automatically). In this case, a separated theme engine is not enough -
it must be tightly integrated into the core of GUI.

Besides, multiple-inheritance is not really error-prone - look at
Eiffel, Common Lisp Object System, Python, etc.
PS: Finally I gave up that GUI.

[John Wood]

I think the cases where you need multiple inheritance are pretty rare, and
when you do need it, some kind of delegation / decorator pattern will
suffice. It's all too easy to choose multiple inheritance and end up with a
worse design, added complexity and often serious problems later on(diamonds
etc.).

In this example, a better design (IMO) would be to have the button "draw
into" a supplied object via a common interface. The supplied object is
plugged in and will represent the theme.

eg.
interface IThemePainter
{
void DrawBackground(rect,state);
void DrawInnerEdge(rect,state);
void DrawText(text, rect,state);
...
}

In fact this is pretty much how it works in XP.

--
John Wood
Blog: http://spaces.msn.com/members/johnwood
"Aquila Deus" <aq*********@yahoo.co.uk> wrote in message
news:11*********************@f14g2000cwb.googlegro ups.com...

I have one - my GUI design:

There are two kinds of GUI controls - Basic controls decide what to do,
and theme controls decide how to do. Each UI *control* (seen by
end-user) actually consists of a basic control and a theme control.

For example, a Button may consist of a BasicButton and a
MacStyleButton. The "Button" itself is an interface. And the real class
(implementation) created is MacStyleButton.

The MacStyleButton must inherit both of (abstract) BasicButton and
MacStyleControl. BasicButton can't just be an interface because it also
defines some common tasks, such as DoClick, Text (property), etc.

And for the theme, traditional theme engines decide only how controls
are rendered, so that they could use something like a ThemeEngine
class, providing RenderButton, RenderMenu, etc. But what if different
themes have different behaviors? For example, selecting a menu item in
windows and that in CDE: In windows you click menu, submenu, then
menuitem; but in CDE you press the button - and don't release, until
the mouse pointer moves to the item you want (submenus are expanded
automatically). In this case, a separated theme engine is not enough -
it must be tightly integrated into the core of GUI.

Besides, multiple-inheritance is not really error-prone - look at
Eiffel, Common Lisp Object System, Python, etc.
PS: Finally I gave up that GUI.

[Aquila Deus]

John Wood wrote:

I think the cases where you need multiple inheritance are pretty rare, and when you do need it, some kind of delegation / decorator pattern will suffice. It's all too easy to choose multiple inheritance and end up with a worse design, added complexity and often serious problems later on(diamonds etc.).
Yes, but conflicts can easily be solved by method/field renaming and
hiding.

After all, developers could still use interface (and they should do so
as much as possible).

In this example, a better design (IMO) would be to have the button "draw into" a supplied object via a common interface. The supplied object is plugged in and will represent the theme.

eg.
interface IThemePainter
{
void DrawBackground(rect,state);
void DrawInnerEdge(rect,state);
void DrawText(text, rect,state);
...
}

In fact this is pretty much how it works in XP.
I also found that when I browsed the winform assembly (btw i think it's
really a dirty wrapper). But as I wrote, it's doesn't work well for
complex design. And the delegation, similiar this method, also requires
you to define what theme engine can do first, which limits the engine's
functionality.

--
John Wood
Blog: http://spaces.msn.com/members/johnwood
"Aquila Deus" <aq*********@yahoo.co.uk> wrote in message
news:11*********************@f14g2000cwb.googlegro ups.com...

I have one - my GUI design:

There are two kinds of GUI controls - Basic controls decide what to do, and theme controls decide how to do. Each UI *control* (seen by
end-user) actually consists of a basic control and a theme control.

For example, a Button may consist of a BasicButton and a
MacStyleButton. The "Button" itself is an interface. And the real class (implementation) created is MacStyleButton.

The MacStyleButton must inherit both of (abstract) BasicButton and
MacStyleControl. BasicButton can't just be an interface because it also defines some common tasks, such as DoClick, Text (property), etc.

And for the theme, traditional theme engines decide only how controls are rendered, so that they could use something like a ThemeEngine
class, providing RenderButton, RenderMenu, etc. But what if different themes have different behaviors? For example, selecting a menu item in windows and that in CDE: In windows you click menu, submenu, then
menuitem; but in CDE you press the button - and don't release, until the mouse pointer moves to the item you want (submenus are expanded
automatically). In this case, a separated theme engine is not enough - it must be tightly integrated into the core of GUI.

Besides, multiple-inheritance is not really error-prone - look at
Eiffel, Common Lisp Object System, Python, etc.
PS: Finally I gave up that GUI.