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. 8 2023
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
"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
"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
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
"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
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.
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.
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. This discussion thread is closed Replies have been disabled for this discussion. Similar topics
20 posts
views
Thread by km |
last post: by
|
22 posts
views
Thread by Matthew Louden |
last post: by
|
47 posts
views
Thread by Mark |
last post: by
|
60 posts
views
Thread by Shawnk |
last post: by
|
15 posts
views
Thread by iKiLL |
last post: by
|
7 posts
views
Thread by Adam Nielsen |
last post: by
|
11 posts
views
Thread by John |
last post: by
|
21 posts
views
Thread by raylopez99 |
last post: by
|
2 posts
views
Thread by Immortal Nephi |
last post: by
| | | | | | | | | | |