Discussion :

[=JBO=]

Bonjour,

En fait le fil de messages originel est à rechercher sur le forum Access/VBA Access qui évoquait la problématique de l'héritage pour les classes développées en VBA: Héritage, possible ou non?

Donc la discussion a quelque peu dévié sur la question du polymorphisme, et s'est retrouvé déplacée sur le forum Général VBA.

_____---====OOOOO====---

Au risque de déborder un peu sur le sujet originel, je souhaite préciser comment on met en œuvre le polymorphisme en VB/VBA.

Ce ne serait pas l'inverse ? ... Implements permet "une sorte" d'héritage, mais pas le polymorphisme... (enfin, c'est ce qu'il me semble...)

D'abord il faut s'entendre sur la signification de polymorphisme.
Aussi, je me reposerai sur Wikipédia avec un court extrait ci-dessous et la suite sur la page de Wikipédia illustrée par un exemple:

En informatique, le polymorphisme est l'idée d'autoriser le même code à être utilisé avec différents types, ce qui permet des implémentations plus abstraites et générales.

Je reprends l'exemple de la page de Wikipédia (merci de vous y reporter) en l'adaptant au VB/VBA.

Une classe-interface cForme décrit les méthodes à implémenter pour toutes les "formes" géométriques:

Code :

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

1
2
3
4
5
Option Explicit
 
Public Function Aire() As Double
    Aire = 0
End Function

Une classe cCarré décrit les formes de type Carré et implémente les méthodes d'une "forme" géométrique.

L'utilisation du mot-clé Implements (dans la partie déclaration du module de classe) spécifie qu'une classe implémente l'interface publique (méthodes et propriétés) d'une autre classe.

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
Option Explicit
 
Implements cForme
 
Private p_nCôté As Double
 
Private Function cForme_Aire() As Double
    cForme_Aire = p_nCôté * p_nCôté
End Function
 
Public Property Get Côté() As Double
    Côté = p_nCôté
End Property
 
Public Property Let Côté(n As Double)
    p_nCôté = n
End Property

Une classe cCercle décrit les formes de type Cercle et implémente les méthodes d'une "forme" géométrique:

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
Option Explicit
 
Implements cForme
 
Private p_nRayon As Double
 
Private Function cForme_Aire() As Double
    cForme_Aire = CDbl(3.1415926535) * p_nRayon * p_nRayon
End Function
 
Public Property Get Rayon() As Double
    Rayon = p_nRayon
End Property
 
Public Property Let Rayon(n As Double)
    p_nRayon = n
End Property

Dans un module de code, on spécifie la fonction AireTotal() qui reçoit en paramètre une collection d'objets "formes" et retourne la somme des aires de ces objets.
C'est ici que le polymorphisme rentre en jeu puisque, selon le type de "forme", la fonction fait toujours appel à la bonne méthode de calcul Aire(). Tout type de "forme" géométrique qui implémente la classe/interface cForme peut être ajouté sans nécessiter une modification de la fonction AireTotal().

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
Public Function AireTotal(collFormes As Collection) As Double
    Dim oForme As cForme
    Dim nTotal As Double
 
    nTotal = 0
 
    For Each oForme In collFormes
        ' la fonction "sait" automatiquement quelle méthode Aire() appeler
        nTotal = nTotal + oForme.Aire()
    Next oForme
 
    AireTotal = nTotal
End Function

Enfin, on peut aussi coder une procédure pour tester tout ça:

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
Public Sub TestFormes()
    Dim oCarré As New cCarré
    Dim oCercle As New cCercle
    Dim collFormes As New Collection
    Dim nTotal As Double
 
    oCarré.Côté = 3.4
    oCercle.Rayon = 5.1
 
    collFormes.Add oCarré
    collFormes.Add oCercle
 
    nTotal = AireTotal(collFormes)
 
    Debug.Print nTotal
End Sub

A l'usage, l'implémentation d'interface permet:
(1) de coder des procédures "génériques" qu'il ne sera pas nécessaire de modifier pour prendre en compte de nouveaux "sous-types" (exemple la fonction AireTotal()),
(2) d'obtenir un code plus robuste parce que les appels de méthodes sont vérifiés à la compilation (liaison dynamique "late binding" mais avec la rigueur du contrôle de type).

Merci aux courageux et curieux qui ont lu jusqu'au bout.
_

[Pierre Fauconnier]

Salut...

Bah... Tant pis pour le débordement...

Dans les exemples que tu proposes, je ne vois pas de polymorphisme (... le même code à être utilisé avec différents types...) puisque les classes Carré et Cercle utilisent le même type (même (absence de) paramètre..., même type renvoyé)...
Pour moi, le polymorphisme, c'est d'avoir deux fonctions de même nom dans une même classe, mais avec la possibilité de passer des paramètres différents

Code :

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

1
2
3
4
5
6
7
function Aire(Cote as double) as double
    ...
end function
 
function Aire(Longueur as double, Largeur as double) as double
    ....
end function

Ce cas est impossible en vba car pas de polymorphisme, alors qu'il est possible en vb.net.

Donc, pour moi, dans ton exemple, on met bien un "pseudo"- héritage dont je ne vois par ailleurs pas vraiment l'intérêt...

[=JBO=]

Bonjour,

Pour moi, le polymorphisme, c'est d'avoir deux fonctions de même nom dans une même classe, mais avec la possibilité de passer des paramètres différents
[...]
Ce cas est impossible en vba car pas de polymorphisme, alors qu'il est possible en vb.net.

Donc, pour moi, dans ton exemple, on met bien un "pseudo"- héritage dont je ne vois par ailleurs pas vraiment l'intérêt...

En fait tu évoques la technique de surcharge de fonction (ou d'opérateur) qui n'est pas particulièrement liée aux langages à/orientés objet. On peut aussi la retrouver dans certains langages fonctionnels ou procéduraux.

Tu assimiles «surcharge de fonction» et «polymorphisme», et c'est une confusion que l'on voit fréquemment sur l'internet.
Dans Wikipédia en anglais l'article sur le polymorphisme expose les choses plus précisément en distinguant différentes formes de polymorphisme:

• ad-hoc polymorphism,
• parametric polymorphsim d'où découle le subtyping polymorphism (ou encore inclusion polymorphism).

La surcharge de fonction relève de l'ad-hoc polymorphism.

L'exécution dynamique de méthode relève du subtyping polymorphism (c'est l'exemple que j'ai donné).

Une différence essentielle entre surcharge et exécution dynamique peut s'expliquer quand on considère l'étape de compilation d'un programme.

En ce qui concerne la surcharge, un compilateur peut déterminer la fonction à appeler au moyen des types des paramètres qui sont déjà connus à la compilation: la liaison est établie dès la compilation du code.

En ce qui concerne une "fonction polymorphe" (comme la fonction AireTotal()) le compilateur ne peut pas connaître la bonne méthode (ici la méthode Aire()) qui sera exécutée car le type réel (la "forme" géométrique) ne sera connu qu'à l'exécution.
_

[Pierre Fauconnier]

Salut...

D'accord avec toi. En faisant des tests, j'ai compris mon mélange entre les deux notions... Merci pour les explications détaillées.

Cela étant, quel est l'intérêt de ce type de polymorphisme en VBA? Dans la pratique, je ne vois pas trop en quoi cela peut aider, si ce n'est à "généraliser" des propriétés "communes" à différentes classes. Si l'intérêt s'arrête là, je trouve que c'est un peu lourd à mettre en place, non?

Ton avis m'intéresse. Merci

[=JBO=]

Cela étant, quel est l'intérêt de ce type de polymorphisme en VBA? Dans la pratique, je ne vois pas trop en quoi cela peut aider, si ce n'est à "généraliser" des propriétés "communes" à différentes classes. Si l'intérêt s'arrête là, je trouve que c'est un peu lourd à mettre en place, non?

Ton avis m'intéresse. Merci

Tout d'abord, l'implémentation d'interface est un des mécanismes fondamentaux de l'architecture COM de Windows, permettant l'intégration de nouveaux types d'objets à l'intérieur de cette infrastructure complexes.
C'est toujours ce même mécanisme qui permet d'étendre les fonctionnalités de l'IDE VB/VBA.

Pour ma part, je m'en suis beaucoup servi dans le cadre de projets complexes en VBA/Access.
En effet, il y a un moment où un grand nombre de formulaires rend difficile (problématique) l'exécution d'une application Access.

J'ai donc "sorti" et factorisé un maximum de codes communs aux formulaires pour coder des fonctions/procédures polymorphes.
Ceci m'a amené à spécifier une classe-interface cFormApp listant les méthodes qu'un formulaire devait implémenter (le mot-clé Implements est autorisé dans le module de code d'un formulaire ou d'un état).
Cette classe-interface était alors utilisée dans mes fonctions/procédures polymorphes.

Ensuite dans les applications Access, j'ai rattaché les fonctions polymorphes aux barres de menus et d'outils. La première tâche de la fonction polymorphe est de récupérer l'objet en cours (le formulaire qui a le focus) puis d'y appliquer le reste du code.

Cette méthode m'a permis:
(1) de développer des gros projets qui se seraient essoufflés à cause du volume formulaire/code (nombre de formulaires divisé par 3 voire 4),
(2) de développer dans de bonnes conditions grâce à une meilleure robustesse du code,
(3) de gérer au mieux l'évolution des applications:
___(3.a) rapidité pour l'ajout d'un nouveau type de formulaire,
___(3.b) ajout de nouvelles fonctionnalités (au niveau de la classe-interface) en limitant les risques d'oublis (la compilation n'étant pas possible sans l'implémentation complète au niveau des formulaires).

Je trouve que c'est lourd à mettre en place pour de petits projets.
Cela pourrait quand même se justifier si on développe du code réutilisable dans de nombreux projets.

En revanche dans des projets "larges" la question de la lourdeur est vite relativisée et cette méthode de travail procure des gains notables.
_

[mout1234]

Salut,

Je découvre par hasard ce post avec beaucoup d'intérêt.

JBO, deux questions stp:

• depuis quand (quelle version Office) existe l'instruction Implements?
• Peux-tu citer quelques exemples de méthodes de ton interface cFormApp, histoire de mieux situer l'avantage de cette méthode de dev qui me plait bien ?
  Je ne vois pas bien notamment ce qui peut ainsi te permettre de diminuer autant ton nombre de formulaires par le seul apport de cette interface.