Dans Visual Basic, un module (Module) permet de déclarer des variables et des procédures accessibles dans tout le projet (avec les bons modificateurs d'accès). Les variables déclarées à l'intérieur d'un module en dehors des procédures deviennent ses champs – leur portée dépend du modificateur (Private/Friend/Public), et leur durée de vie est égale à celle de l'application.
Caractéristiques clés des variables de module :
Contrairement aux variables globales (par exemple, dans d'autres langages ou l'ancien VB6), les variables de module ne sont pas accessibles en dehors de l'assemblage, à moins qu'elles ne soient explicitement déclarées comme Public.
Exemple :
Module Globals Public Counter As Integer Sub Increment() Counter += 1 End Sub End Module ' Accès à Counter depuis n'importe où dans le même projet
Question : Quel accès à une variable de module sera-t-il lors de sa déclaration avec le modificateur Private ? Est-elle accessible depuis d'autres modules du même projet ?
Réponse : Non, une variable avec le modificateur Private est accessible uniquement à l'intérieur de ce module – d'autres modules ou classes ne peuvent pas y accéder.
Module Data Private x As Integer End Module ' Module Other ne verra pas x
Histoire
Lors du développement d'un service de calcul, toutes les valeurs des résultats intermédiaires étaient stockées dans des variables de module. Un des développeurs supposait que les données "seraient réinitialisées" entre les appels, mais l'état était conservé (Portée de l'application). Cela a conduit à des erreurs lors de l'utilisation simultanée du service par plusieurs utilisateurs. Solution : utiliser des variables locales et éviter de conserver l'état dans les modules si la sûreté des threads est requise.
Histoire
Dans un projet multi-fichiers, une variable de module a été déclarée avec le modificateur
Friend(au lieu dePublic). On s'attendait à ce qu'elle soit accessible dans tous les projets liés de la solution, mais elle s'est révélée uniquement visible à l'intérieur d'un seul assemblage, ce qui a causé des erreurs d'accès inattendues lors de l'intégration.
Histoire
Après l'optimisation du code, les flags logiques du processus ont cessé de fonctionner, car le constructeur de la classe ne recevait pas le module où le flag log-stat était défini. Au final, une ancienne version de la valeur était utilisée, ce qui a conduit le système à fonctionner avec des données obsolètes, et le bug a été longtemps enquêté en raison de la difficulté à tracer le point de changement de l'état de la variable de module.