Discussion :

[stracoma]

Bonsoir tout le monde. j'ai besoin de votre aide.

Pour comprendre la notion de Polyorphsme dans VB, j'ai essayé ce petit exemple

Code :

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

1
2
3
4
5
6
7
8
9
10
Module Module1
 
    Sub Main()
        Dim damien As humain
        damien = New espagnol
        damien.parle()
        Console.ReadKey()
    End Sub
 
End Module

Classe mère:

Code :

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

1
2
3
4
5
Public Class humain
    Public Overridable Sub parle()
        Console.WriteLine("tout humain parle")
    End Sub
End Class

Classe fille:

Code :

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

1
2
3
4
5
6
7
8
Public Class espagnol
    Inherits humain
 
    Public Overloads Sub parle()
        Console.WriteLine("Il parle espagnol")
    End Sub
 
End Class

Je m'attends à ce que (parle()) de espagnol qui s'exécute. Mais mon code affiche "tout humain parle"

Est ce que quelqu'un peut me donner une explication?

Merci

[rv26t]

Bonjour,

Il faut utiliser le mot clé Overrides (ce qui signifie qu'une procédure substitue une procédure du même nom héritée d'une classe de base.)

Code :

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

1
2
3
4
5
6
7
8
Public Class espagnol
    Inherits humain
 
    Public Overrides Sub parle()
        Console.WriteLine("Il parle espagnol")
    End Sub
 
End Class

[Pol63]

overloads est à utiliser quand on a plusieurs méthodes de même nom mais de signature différente (signature = paramètres en nombre et en type)
le plus généralement au sein d'une même classe

Code :

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

1
2
3
4
5
 
overloads sub a()
 
 
overloads sub a(nb as integer)

[mactwist69]

Moi j'ai jamais compris à quoi servait overloads, puisque ça marche sans.

Voir, si on utilise overloads sur une méthode, il faut le faire sur toute les autres (même en héritage)...

Pourquoi rendre ce système de surcharge contraignant ?

[Kropernic]

Pareil, je ne me sers que de overrides. Overloads, ça ne fait que surcharger le code je trouve...

Enfin, si les méthodes sont éparpillées un peu partout, l'ajout de overloads peut être pertinent pour attirer l'attention.

Personnellement, je regroupe les méthodes de même nom et de signatures différentes les unes en dessous des autres.

[mactwist69]

l'ajout de overloads peut être pertinent pour attirer l'attention

-> Effectivement, dans ce cas ça pourrait servir. Mais comme toi j'organise le code, notamment par région, je me vois mal avoir les mêmes procédures surchargées éparpillées de partout.

Par contre quand j'utilise le polymorphisme en héritage, j'utilise MustOveriddes dans la classe mère, pour forcer les classes enfants à suivre un même schéma. Mais là pour le coup, ce n'est pas un simple indicateur.

[Invité]

Moi j'ai jamais compris à quoi servait overloads, puisque ça marche sans.

Voir, si on utilise overloads sur une méthode, il faut le faire sur toute les autres (même en héritage)...

Pourquoi rendre ce système de surcharge contraignant ?

Salut,

Bien que je ne sois pas un expert en POO sur VB, il me semble avoir déjà utilisé Overloads par obligation, mais je ne retrouve plus l'exemple. Shadows ne fonctionnait pas et Overloads fonctionnait.

J'ai essayé de refaire un exemple (calamiteux certes) de sorte qu'il faille rendre obligatoire Overloads bien que le code n'est pas forcément de sens d'ailleurs:

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
31
32
33
34
35
36
37
38
39
 
Imports Vb = Microsoft.VisualBasic
Module MainModule
    Sub Main()
        Dim a As EtreVivant = New EtreVivant
        Dim b As EtreVivant = New Humain
        Dim c As Humain = New Humain
        a.SeNourrit()
        a.SeNourrit(True)
        b.SeNourrit()
        b.SeNourrit(True)
        c.SeNourrit()
        c.SeNourrit(True)
    End Sub
End Module
 
Public Class EtreVivant
 
    Public Sub SeNourrit(Arg1 As Boolean)
        Vb.MsgBox("Etre vivant se nourrit - [EtreVivant.SeNourrit(Boolean)]")
    End Sub
 
    Public Overridable Sub SeNourrit()
        Vb.MsgBox("Etre vivant se nourrit simplement - [EtreVivant.SeNourrit(void)]")
    End Sub
 
End Class
 
Public Class Humain : Inherits EtreVivant
 
    Public Overloads Sub SeNourrit(Arg1 As Boolean)
        Vb.MsgBox("Humain se nourrit - [Humain.SeNourrit(Boolean)]")
    End Sub
 
    Public Overloads Overrides Sub SeNourrit()
        Vb.MsgBox("Humain se nourrit - [Humain.SeNourrit(void)]")
    End Sub
 
End Class

En principe, en supprimant Overloads, cela ne devrai pas fonctionner.

[stracoma]

Merci à vous. Je suis débutant. Mon erreur est que dans la saisie automatique au lieu de cliquer sur Overrides , j'ai cliqué sur overloads (que je n'ai pas encore étudié).
Donc avec Overrides le code marche.
Merci beaucoup à vous

[sinople]

Sauf erreur je crois que Overload est utile dans le cas ou une class enfant redéfinit une méthode de son parent en changeant la signature.

[Invité]

Oui, effectivement, sans hiérarchie d'héritage, Overloads n'est pas obligatoire.
C'est pour ça que je ne l'ai mis que dans la classe Fille pour montrer son caractère obligatoire dans celle-ci uniquement.

[rv26t]

Sauf erreur je crois que Overload est utile dans le cas ou une class enfant redéfinit une méthode de son parent en changeant la signature.

Exact,
utilisons l'exemple de stracoma, nous pouvons avoir un humain qui parle plusieurs langue

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
Public Class HumainMultiLingue
    Inherits humain
 
    Public Overloads Sub parle(Langue As String)
        Select Case Langue
            Case "fr"
                Console.WriteLine("Il parle français")
            Case "en"
                Console.WriteLine("Il parle anglais")
            Case "es"
                Console.WriteLine("Il parle espagnol")
            Case Else
                Console.WriteLine("Il ne parle pas cette langue")
        End Select
    End Sub
 
End Class

Seule cette nouvelle méthode surchargée peut être défini si on le souhaite (parle est hérité), et il faut le mot Overloads pour indiquer qu'elle surcharge (nouvelle signature) des méthodes ayant le même nom dans la classe parent.
On l'utilise ainsi

Code :

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

1
2
3
4
5
        Dim Jean As HumainMultiLingue = New HumainMultiLingue
        Jean.parle() '>"tout humain parle"
        Jean.parle("fr") '>"Il parle français"
        Jean.parle("de") '>"Il ne parle pas cette langue"
        Console.ReadKey()

On peut l'attribuer à un "humain", mais la méthode surchargée n'existant pas dans la classe "humain", on est obligé de la remettre dans son type pour l'exploiter.

Code :

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

1
2
3
4
5
        Dim damien As humain
        damien = New HumainMultiLingue
        damien.parle() '>"tout humain parle"
        DirectCast(damien, HumainMultiLingue).parle("es") '>"Il parle espagnol"
        Console.ReadKey()

[Edit]
On pourrait aussi redéfinir la méthode Parle dans la classe HumainMultiLingue (de façon classique)

Code :

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

1
2
3
    Public Overrides Sub parle()
        Console.WriteLine("Il parle plusieurs langues.")
    End Sub

[mactwist69]

J'ai eu un petit doute du coup j'ai fais un test et il s'avère que : qu'il y ait changement de signature ou pas dans la classe fille, le même warning (erreur?) apparaît :

sub 'test' shadows an overloadable member declared in the base class 'mere'. If you want to overload the method, this method must be declared Overloads

C'est donc systématique.

Et Overloads appliqué ou non à la méthode de la classe mère ne change rien.

[rv26t]

Peux-tu préciser ton contexte de test.
shadows masque toutes les méthodes ayant le même nom de la classe parent. Toutes les méthodes redéfini portant toujours ce même nom doivent être shadows.

Ici par exemple

Code :

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

1
2
3
4
5
6
7
8
9
10
11
Public Class Humain : Inherits EtreVivant
 
    Public Overloads Sub SeNourrit(Arg1 As Boolean)
        Vb.MsgBox("Humain se nourrit - [Humain.SeNourrit(Boolean)]")
    End Sub
 
    Public Overloads Overrides Sub SeNourrit()
        Vb.MsgBox("Humain se nourrit - [Humain.SeNourrit(void)]")
    End Sub
 
End Class

En principe, en supprimant Overloads, cela ne devrai pas fonctionner.

Seule la méthode n'étant pas Overridable a besoin d'Overloads
La méthode défini avec Overridable (signifie qu'une procédure peut être substituée par une procédure de même nom (signature) dans une classe dérivée.) n'en a pas besoin

Code :

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

1
2
    Public Overrides Sub SeNourrit()
'...

est ok

Si l'une des 2 avait été marquée shadows, l'autre doit l'être aussi. et dans ce cas on ne précise plus Overloads ou Overrides. [Edit] Par contre elles peuvent être Overridable pour permettre la redéfinition.

[Invité]

J'ai eu un petit doute du coup j'ai fais un test et il s'avère que : qu'il y ait changement de signature ou pas dans la classe fille, le même warning (erreur?) apparaît :

sub 'test' shadows an overloadable member declared in the base class 'mere'. If you want to overload the method, this method must be declared Overloads

C'est donc systématique.

Et Overloads appliqué ou non à la méthode de la classe mère ne change rien.

Salut,

Non puisque du coup, comme dit plus haut, Shadows doit ou peut être utilisé dans le cas d'une signature identique, donc Overloads n'est pas obligatoire.

[Invité]

Seule la méthode n'étant pas Overridable a besoin d'Overloads
La méthode défini avec Overridable (signifie qu'une procédure peut être substituée par une procédure de même nom (signature) dans une classe dérivée.) n'en a pas besoin

Code :

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

1
2
    Public Overrides Sub SeNourrit()
'...

est ok

Si l'une des 2 avait été marquée shadows, l'autre doit l'être aussi. et dans ce cas on ne précise plus Overloads ou Overrides.

Bien vu alors.
Je ne savais pas qu'Overrides pouvait remplacer Overloads Overrides.
Habituellement, Un Overloads sur 1 méthode entraine automatiquement l'ajout d'Overloads sur les autres.

[rv26t]

Habituellement, Un Overloads sur 1 méthode entraine automatiquement l'ajout d'Overloads sur les autres.

Toutes celles (même nom) qui ne sont pas Overrides.
Et si l'on veut qu'elles puissent être redéfinies dans les classes filles, il faut les mettre Overridable Overloads.

Code :

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

    Public Overridable Overloads Sub SeNourrit(Arg1 As Boolean)

[mactwist69]

Quand j'ai recopié l'erreur :

sub 'test' shadows an overloadable member declared in the base class 'mere'. If you want to overload the method, this method must be declared Overloads

Shadows, dans la phrase, n'est pas une fonctionnalité mais un verbe.
Traduction : "La méthode test cache (fait de l'ombre) à un membre overloadable..."

Seule la méthode n'étant pas Overridable a besoin d'Overloads

-> C'est ce que je confirmais, et j'ajoutais que la signature peut être identique ou pas, c'est pareil.

Code :

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

 Public Overridable Overloads Sub SeNourrit(Arg1 As Boolean)

-> Mais ça, je vois pas l'intérêt, car ces éléments s'annulent :
Overridable dans la classe mère permet de ne pas utiliser Overloads dans la classe fille,
alors pourquoi utiliser derrière Overloads sur la classe mère pour obliger la classe fille à le déclarer Overloads aussi.

Pour moi ça revient à ne rien mettre dans la classe mère, et dans la classe fille on devra utiliser Overloads.

[rv26t]

Code :

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

 Public Overridable Overloads Sub SeNourrit(Arg1 As Boolean)

-> Mais ça, je vois pas l'intérêt, car ces éléments s'annulent :
Overridable dans la classe mère permet de ne pas utiliser Overloads dans la classe fille,
alors pourquoi utiliser derrière Overloads sur la classe mère pour obliger la classe fille à le déclarer Overloads aussi.

C'est parceque l'exemple est mal conçu. (c'était le but) pour montrer l'obligation d'utiliser overloads .
Mais là cela ne s'annule pas. Si l'on ne met pas Overridable la méthode ne pourra pas être substituée dans la classe fille. Il faudra de nouveau la marquer (dans la classe fille) Overloads. Afin d'éviter cela on précise Overridable, et dans la fille on mettra Overrides (ce qui aurait du être fait au début).

Pour moi ça revient à ne rien mettre dans la classe mère, et dans la classe fille on devra utiliser Overloads.

C'est une effectivement une autre aproche.
Si on les marque toutes overloads on ne sais plus celles qui sont substituées. si on utilise Overridable et Overrides, c'est seulement celles substituées, les nouvelles étant marqués overloads, on connait celles substituées et celles qui sont nouvelles sans aller voir dans les classes parents.
Je ne sais pas ce qui est le mieux. Je ne suis pas expert en POO.

[Invité]

Bonjour,


Je revient un petit peu sur ce qui a été dit après avoir compris un peu mieux.

Dans mon exemple initial, la configuration choisi rends le mot clé Overloads obligatoire sur tous les autres membres de même nom situé dans les même classe pour les raisons suivantes:

- Un membre (occultant) utilisant le modificateur Overrides est Overloads par défaut.
- Un membre occultant à l'exception des membres Overrides est Shadows par défaut, mais peut être Overloads si définit explicitement.
- Il n'est pas possible de combiner Overloads et Shadows dans un même groupe de surcharge.
- (... il y a encore d'autres règles mais pas utile pour cette exemple.)

ça implique que les 2 méthodes occultantes de même nom situé dans la même classe et dont l'une est spécifié Overrides (Implicitement Overrides Overloads) entraine l'obligation que l'autre méthode spécifie explicitement Overloads également puisque la 2ème méthode est Shadows par défaut (et non Overloads) parce qu'elle ne spécifie pas Overrides aussi.

Sinon, dans une configuration plus classique, Overloads permet d'éviter le Shadows implicite donc lors d'une hiérachie d'héritage. Il permet d'éviter le masquage de toutes les procédures héritées de même nom (utilisé par défaut).
Ecrire explicitement Shadows supprime l'avertissement et si on ne souhaite que masquer la procédure héritée de même nom/signature, on peut utiliser Overloads, mais les 2 ne sont pas combinable entre procédures de même nom dans la même classe.


Donc, tout s'explique finalement.

[Kropernic]

Hello,

Je me permets de poser une question supplémentaire car j'ai justement un problème de polymorphisme ^^.

Voici le cas concret.

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
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
Public Class PromoDetail
    Public Property DTO As PROMO_ICT_DTO.PromoDetail
 
    Public Sub New(d As PROMO_ICT_DTO.PromoDetail)
        Me.DTO = d
    End Sub
 
    Public Function GetProducts() As List(Of PROMO_ICT_DTO.Product)
        If Me.DTO.Products.Count > 0 Then
            Return Me.DTO.Products
        ElseIf Me.DTO.ProductsOut.Count > 0 Then
            Return Me.DTO.ProductsOut
        Else
            Return Nothing
        End If
    End Function
End Class
 
Public Class PromoDetailDemo
    Inherits PromoDetail
 
    Public Shadows Property DTO As PROMO_ICT_DTO.PromoDetailDemo
 
    Public Sub New(dtd As PROMO_ICT_DTO.PromoDetailDemo)
        MyBase.New(dtd)
    End Sub
 
    'Public Function GetProducts() As List(Of PROMO_ICT_DTO.Product)
    '    If Me.DTO.Products.Count > 0 Then
    '        Return Me.DTO.Products
    '    ElseIf Me.DTO.ProductsOut.Count > 0 Then
    '        Return Me.DTO.ProductsOut
    '    Else
    '        Return Nothing
    '    End If
    'End Function
End Class
 
Public Class PromoDetailOwn
    Inherits PromoDetail
 
    Public Shadows Property DTO As PROMO_ICT_DTO.PromoDetailOwn
 
    Public Sub New(dto As PROMO_ICT_DTO.PromoDetailOwn)
        MyBase.New(dto)
    End Sub
 
    'Public Function GetProducts() As List(Of PROMO_ICT_DTO.Product)
    '    If Me.DTO.Products.Count > 0 Then
    '        Return Me.DTO.Products
    '    ElseIf Me.DTO.ProductsOut.Count > 0 Then
    '        Return Me.DTO.ProductsOut
    '    Else
    '        Return Nothing
    '    End If
    'End Function
End Class

En l'état, ça ne fonctionne pas car quand je tente d'accéder à la propriété DTO d'un objet de type PromoDetailDemo ou PromoDetailOwn, le code essaie d'accéder à celle qui est dans la classe mère et qui vaut Nothing (donc NullReferenceException). En pas à pas, je vois deux propriétés DTO dans l'objet mais lors du codage, l'intellisense n'en montre qu'une.

J'ai tenté en mettant la propriété de la classe mère en Overridable et mettre Overrides dans les classes filles mais VS gueule car les types de retour ne sont pas les mêmes.

Comment faut-il faire alors ??