Réponse.

Les modules (Module) dans Visual Basic sont historiquement utilisés pour stocker des procédures, des fonctions et des variables accessibles dans tout le projet sans création explicite d'une instance. Avec l'introduction des classes, leurs rôles se chevauchent partiellement, mais des différences essentielles subsistent.

Historique :

Dans le Visual Basic classique (VB6), les modules étaient le seul moyen de regrouper des fonctions communes et des variables globales. Dans VB.NET, les modules sont restés, mais avec des capacités élargies des classes.

Problème :

Le développeur peut ne pas comprendre la différence entre un module et une classe, ce qui peut conduire à un choix erroné de la méthode de stockage de la logique, à une duplication accidentelle de code ou à un comportement inattendu des variables.

Solution :

Le choix entre un module et une classe dépend des objectifs :

Les modules sont destinés à stocker des procédures et des variables qui doivent être accessibles dans toute l'application sans création d'une instance.
Les classes sont appropriées pour encapsuler l'état et le comportement des objets avec possibilité d'héritage.

Exemple de code :

' Module
Module MathUtils
    Public Function Add(x As Integer, y As Integer) As Integer
        Return x + y
    End Function
End Module

' Utilisation
Dim result = MathUtils.Add(5, 10)

Caractéristiques clés :

Tous les membres du module sont toujours Shared et accessibles sans instance.
Le module ne supporte pas l'héritage ou la création d'instances.
Un module ne peut pas être déclaré comme Friend/Protected à l'intérieur d'une classe.

Questions pièges.

Si une variable est déclarée dans un module comme Public, sera-t-elle commune à tous les formulaires/classes de l'application ?

Oui. Les variables Public dans un module sont essentiellement globales. Elles sont accessibles depuis n'importe quel code du projet, ce qui est pratique, mais peut entraîner des erreurs en cas de multithreading ou de réécriture accidentelle des valeurs.

Peut-on créer une instance d'un module avec New ?

Non. Les modules ne sont pas instanciés. Toute leur fonctionnalité est accessible statiquement.

Peut-on hériter d'un module ou déclarer un module avec des modificateurs d'accès Protected ou Private ?

Non. Les modules ne sont pas héritables et ne peuvent être déclarés qu'au niveau de l'espace de noms (namespace), ne peuvent pas être imbriqués ou avoir d'autres modificateurs d'accès que Public ou Friend.

Erreurs typiques et anti-patterns

Utilisation de variables globales sans contrôle d'accès.
Stockage de l'état utilisateur dans un module au lieu d'une classe (non valide pour le multithreading).
Déclaration de fonctions dupliquées dans différents modules.

Exemple de la vie réelle

Cas négatif

Dans un projet, toutes les variables d'état utilisateur sont déclarées comme Public dans un module. Dès qu'une valeur change dans un formulaire, elle devient instantanément nouvelle pour tous les autres.

Avantages :

Accès global rapide aux variables.

Inconvénients :

Réécriture et bugs difficiles à détecter.
Ne fonctionne pas dans des scénarios multithread — conditions de concurrence.
Maintenance complexe.

Cas positif

Le module est utilisé uniquement pour stocker des utilitaires d'assistance (par exemple, des fonctions de conversion), tandis que l'état utilisateur est stocké dans des classes avec encapsulation.