Héritage et Polymorphisme

Version imprimable

13/08/2014, 15h42
mactwist69

Héritage et Polymorphisme

Bonjour collègue travailleurs de l'été !

J'ai la mission de développer une bibliothèque de classe toute neuve, répondant à tous nos besoins, et j'ai carte blanche !

J'ai fais donc des recherches pour essayer de faire quelque chose de très propre et j'ai quelques petites questions pratiques sur le polymorphisme et l'héritage :

- est il possible d'avoir dans la classe mère une procédure commune A (exclusif a la classe mère), fasse appel à une procédure B, dont le contenu serait vide dans la classe mère (et à MustOverride), du coup elle serait obligatoirement implémenté dans les classe filles. Ma question est, est ce qu'avec le mécanisme de polymorphisme, lorsque A appel B, la classe mère, va chercher B dans la classe fille correspondante ?

- Pourquoi on ne peut pas mettre le constructeur en MustOverride ? Moi j'aimerai que lorsqu'un développeur va créer une nouvelle classe fille, on l'oblige à créer son constructeur...

Ça n'aurait aucun sens d'avoir un constructeur en MustOverride, en effet ce mot clef sert à dire que l'appel est résolu en fonction du type concret de l'objet plutôt que du type de la variable que l'on manipule ; or dans le cas d'un constructeur on précise le type concret que l'on souhaite utiliser donc on sait déjà où va "partir" l'appel.
Après rien ne t'empêche dans ta classe de base de définir un constructeur paramétré, ainsi les classes en héritant devront forcément au moins définir un constructeur (étant donné qu'aucun constructeur par défaut n'est accessible dans la classe parent)

Pour ce qui est d'utiliser une méthode dans la classe de base qui appelle une procédure définie comme MustOverride (et donc la classe est en MustInherit), à l'utilisation ce sera bien dépendant du type concret, comme expliqué plus haut (et donc ça appellera bien la version de la classe fille). Attention toutefois, si jamais la classe fille redéfinit l'autre méthode (celle que tu as nommée A) en utilisant Shadows ou Overloads [ou sans rien mettre au prix d'un warning] et que tu utilises cette méthode A, là les choses vont changer, ça dépendra du type de la variable utilisées pour l'appel

Moralité si tu veux être sûr que le polymorphisme s'applique, il faudra bien veiller à manipuler ta hierarchie en tant qu'instances concrètes stockées sous forme de base.

Ci-joint un exemple de code vite fait, pour résumer :
Code:

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 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 Sub Main() Dim simple As New DerivedSimple Dim overload As New DerivedOverloads Dim shadow As New DerivedShadows Console.WriteLine("Calling using ""real type""") simple.A() overload.A() shadow.A() Console.WriteLine() Console.WriteLine("Calling using ""base type""") ' array of derived typed as base Dim bases As Base() = {simple, overload, shadow} Array.ForEach(bases, Sub(b) b.A()) End Sub MustInherit Class Base Sub A() Console.WriteLine("Inside Base.A()") B() End Sub Protected MustOverride Sub B() End Class Class DerivedSimple Inherits Base Protected Overrides Sub B() Console.WriteLine("Inside DerivedSimple.B()") End Sub End Class Class DerivedOverloads Inherits Base Overloads Sub A() Console.WriteLine("Inside DerivedOverloads.A()") Console.WriteLine("No I'm not going to call B()") End Sub Protected Overrides Sub B() Console.WriteLine("Inside DerivedOverloads.B()") End Sub End Class Class DerivedShadows Inherits Base Shadows Sub A() Console.WriteLine("Inside DerivedShadows.A()") Console.WriteLine("No I'm not going to call B()") End Sub Protected Overrides Sub B() Console.WriteLine("Inside DerivedShadows.B()") End Sub End Class ' output: ' Calling using "real type" ' Inside Base.A() ' Inside DerivedSimple.B() ' Inside DerivedOverloads.A() ' No I'm not going to call B() ' Inside DerivedShadows.A() ' No I'm not going to call B() ' Calling using "base type" ' Inside Base.A() ' Inside DerivedSimple.B() ' Inside Base.A() ' Inside DerivedOverloads.B() ' Inside Base.A() ' Inside DerivedShadows.B()

13/08/2014, 16h42
mactwist69

Merci déjà de la réponse rapide !! Qui plus est, très pertinente !

Citation:

Envoyé par Sehnsucht

Ça n'aurait aucun sens d'avoir un constructeur en MustOverride, en effet ce mot clef sert à dire que l'appel est résolu en fonction du type concret de l'objet plutôt que du type de la variable que l'on manipule ; or dans le cas d'un constructeur on précise le type concret que l'on souhaite utiliser donc on sait déjà où va "partir" l'appel.

-> C'est pas faux ! :oops: En fait c'était juste pour faire une contrainte aux développeurs de classe dérivées.

Citation:

Envoyé par Sehnsucht

Après rien ne t'empêche dans ta classe de base de définir un constructeur paramétré, ainsi les classes en héritant devront forcément au moins définir un constructeur (étant donné qu'aucun constructeur par défaut n'est accessible dans la classe parent)

-> C'est pas bête, mieux en fait même ! :P

Citation:

Envoyé par Sehnsucht

Pour ce qui est d'utiliser une méthode dans la classe de base qui appelle une procédure définie comme MustOverride (et donc la classe est en MustInherit), à l'utilisation ce sera bien dépendant du type concret, comme expliqué plus haut (et donc ça appellera bien la version de la classe fille).

-> C'est exactement ce à quoi je pensais : Faire A dans la classe de base, ainsi les développeurs n'auront pas à effectuer dans chaque classe dérivée les différents contrôles de contraintes communes... Mais par contre les laisser développer la partie spécifique au type dérivée.

Citation:

Envoyé par Sehnsucht

Attention toutefois, si jamais la classe fille redéfinit l'autre méthode (celle que tu as nommée A) en utilisant Shadows ou Overloads [ou sans rien mettre au prix d'un warning] et que tu utilises cette méthode A, là les choses vont changer, ça dépendra du type de la variable utilisées pour l'appel

-> Je vais essayer de pas du tout toucher à ces fonctionnalités pour garder les choses assez simples. Du coup j'interdirai même la redéfinition de A dans la classe de base, et j'obligerai la redéfinition de B. Et c'est plus simple pour tout le monde...

Merci des réponses, c'est parfait !
13/08/2014, 16h59
Sehnsucht

Citation:

Envoyé par mactwist69

-> C'est pas bête, mieux en fait même ! :P

Par contre de cette manière tu "obliges" juste la présence d'un constructeur, t'as aucun contrôle sur la signature. Comprendre c'est pas parce que tu spécifies Sub New(s As String) que les héritiers doivent respecter la même signature ils doivent juste avoir un constructeur qui en premier lieu appelle le constructeur parent

Citation:

Envoyé par mactwist69

-> Je vais essayer de pas du tout toucher à ces fonctionnalités pour garder les choses assez simples. Du coup j'interdirai même la redéfinition de A dans la classe de base, et j'obligerai la redéfinition de B. Et c'est plus simple pour tout le monde...

Pas sûr de bien comprendre, mais si tu comptes trouver un moyen d'empêcher aux héritiers d'utiliser Shadows/Overloads je te souhaite bonne chance, parce qu'à ma connaissance il n'en existe pas (à part justement en passant par le constructeur qui n'est pas "Shadowable/Overloadable")
14/08/2014, 09h10
mactwist69

Citation:

Envoyé par Sehnsucht

Par contre de cette manière tu "obliges" juste la présence d'un constructeur, t'as aucun contrôle sur la signature. Comprendre c'est pas parce que tu spécifies Sub New(s As String) que les héritiers doivent respecter la même signature

->Got it

Citation:

Envoyé par Sehnsucht

ils doivent juste avoir un constructeur qui en premier lieu appelle le constructeur parent

-> Je ne m'étais pas posé la question, mais effectivement, ça tombe sous le sens. J'imagine qu'un MyBase.New() fait l'affaire.

Citation:

Envoyé par Sehnsucht

si tu comptes trouver un moyen d'empêcher aux héritiers d'utiliser Shadows/Overloads

-> Nan, c'est juste moi qui me mets des limites. Je n'utiliserai pas Shadow pour pas compliquer le programme. Si déjà tout le reste va bien et est bien conçu, il ne devrait pas y avoir de problème.