Discussion :

[syntaxerror]

Bonjour,

je suis confronté, dans plusieurs projets, à des problèmes d'héritage multiple (j'aimerai en mettre alors que ca n'est pas possible).

Pour situer le contexte : je tend à partager mon code en module, avec généralement une partie logique métier et un partie interface : en ce moment j'essaye de faire un petit simulateur de circuits logiques (en Silverlight), qui permet de placer sur un plan de travail des portes logiques et de les relier entre elles pour obtenir un résultat.

Du point de vue du code métier, j'ai une classe de base Operation, de laquelle j'hérite OperationEt, OperationOu, ... La classe mère possède la spécification de l'interface (fonction ObtenirResultat, ...) et quelques fonctions communes spécifiées (ce qui m'empêche d'en faire une interface).

Pour le coté interface graphique, je pense utiliser une version un peu modifiée de la classe Rectangle, qui est donc concrète également.

Du coup, mes portes logiques sur le plan de travail sont des classes PorteEt, PorteOu... qui devraient hériter à la fois de leur classe métier correspondante et à la fois de la classe liée à l'affichage.

Et ca n'est pas possible.

Pourtant le découpage me semble classique, non ?

Alors quelle est la méthode préconisée dans ces cas la ?

Merci

[chamamo]

Bonjour,


L’héritage multiple n’est pas possible en c# car si t'as une classe C qui hérite des classes A et B pour lesquelles une même méthode m est définie, il n'est pas possible de savoir, quand tu fais C.m(), s'il faut appeler la méthode définie dans A ou celle définie dans B.

Pour détourner ça on implémente plusieurs interfaces, donc Operation devrait être une interface, et OperationEt, OperationOu des interfaces qui héritent de l’interface opération.
Et les fonctions communes qui se trouvent dans Operation doivent être implémentées dans la classe qui implémente une de ces interfaces (Rectangle dans ton exemple).

Là tu vas me dire que si j’ai une autre classe Triangle qui implémente l’interface Operation, doit être aussi ré-implémenter ces fonctions (code dupliqué), oui malheureusement

la solution est d'utiliser les méthodes d’extensions si tu es en 3.0,

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
interface IOperation
    {
        void Method();
    }
 
    interface IOperationEt : IOperation
    {
        void MethodeEt();
    }
 
    interface IOperationOu : IOperation
    {
        void MethodeOu();
    }

la classe Rectangle personnalisée:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
 
class CustomRectangle : Rectangle, IOperationEt, IOperationOu
    {
        #region IOperationEt Members
 
        public void MethodeEt()
        {
            ...
        }
 
        #endregion
 
        #region IOperation Members
 
        public void Method()
        {
            ...
        }
 
        #endregion
 
        #region IOperationOu Members
 
        public void MethodeOu()
        {
            ...
        }
 
        #endregion
    }

et pour la méthode d'extension:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
static class ClassExtensions
    {
        public static void OperationMethodeExtension(this IOperation op)
        {
            //Méthode commune
        }
    }

ce qui te permetra de faire:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
CustomRectangle rec=new CustomRectangle ();
rec.OperationMethodeExtension();

[hegros]

Du coup, mes portes logiques sur le plan de travail sont des classes PorteEt, PorteOu... qui devraient hériter à la fois de leur classe métier correspondante et à la fois de la classe liée à l'affichage.

Et ca n'est pas possible.

Pourtant le découpage me semble classique, non ?

Non ce n'est pas un découpage classique. Une classe métier n'hérite pas d'une classe liée à l'affichage, à la rigueur l'inverse, donc c'est plutôt une erreur de conception.

Pour l'interface graphique il vaut mieux encore composé (et pas hérité) avec une interface de rectangle

[Bluedeep]

Bonjour,

je suis confronté, dans plusieurs projets, à des problèmes d'héritage multiple (j'aimerai en mettre alors que ca n'est pas possible).

N'en déplaise aux fan du C++, quand on commence comme cela, ça traduit en général une erreur de conception.

Pour situer le contexte : je tend à partager mon code en module, avec généralement une partie logique métier et un partie interface : en ce moment j'essaye de faire un petit simulateur de circuits logiques (en Silverlight), qui permet de placer sur un plan de travail des portes logiques et de les relier entre elles pour obtenir un résultat.

Jusque là rien à dire.

Du point de vue du code métier, j'ai une classe de base Operation, de laquelle j'hérite OperationEt, OperationOu, ... La classe mère possède la spécification de l'interface (fonction ObtenirResultat, ...) et quelques fonctions communes spécifiées (ce qui m'empêche d'en faire une interface).

Là on tend vers l'héritage d'implémentation, ce qui n'est pas forcément une bonne idée ...

Du coup, mes portes logiques sur le plan de travail sont des classes PorteEt, PorteOu... qui devraient hériter à la fois de leur classe métier correspondante et à la fois de la classe liée à l'affichage.

C'est absolument illogique de faire hériter une classe métier d'une classe d'affichage.

Pourtant le découpage me semble classique, non ?

Non, pas du tout.

Alors quelle est la méthode préconisée dans ces cas la ?

Merci

L'aggrégation.

Pour la n-ième fois, l'héritage ne sert pas à réutiliser du code, l'agrégation est là pour cela. L'héritage permet de faire des regroupements sémantiques.