L'utilisation de modules en VB.NET est-elle considérée comme une mauvaise pratique ?

Question

Lors de la conception d'une nouvelle application, je me demandais si l'utilisation d'un module avec des propriétés était considérée comme une mauvaise pratique.

Quelques exemples de code :

Module modSettings

   public property Setting1 as string

   public property DatabaseObject as IDatabaseObject

End Module

Le code ci-dessus est juste un exemple pour souligner ma question. Dans le passé, cette structure était très utilisée dans VB6. Par le passé, je l'ai également utilisée dans mes projets .NET.

Mais aujourd'hui, avec des mots à la mode tels que l'injection de dépendance, la testabilité et la séparation des préoccupations, la structure ci-dessus sent mauvais. Je ne peux pas vraiment décrire pourquoi, mais cela ne me semble pas correct. Je dois admettre que je ne suis pas encore très familier avec les mots-clés ci-dessus.

Je me demande donc si le code ci-dessus est réellement es une mauvaise pratique. Si c'est le cas, comment utiliseriez-vous un Module pour ?

Answer 1

Centro a raison de dire qu'un module (ou une classe non héritable avec des membres partagés) est l'outil le plus efficace pour la gestion de l'information. le plus proche équivalent à une classe statique C# . Techniquement, il n'y a donc rien de mal à cela, car il s'agit simplement de l'une des méthodes utilisées par VB pour créer ce type de classe. Par exemple, vous ne pouvez pas dire Public Shared Class Settings en VB, car il n'est pas possible de mettre le Shared sur une classe.

En soi, je ne dirais pas qu'il s'agit d'une mauvaise pratique si une circonstance spécifique nécessite un module, mais autrement, un module (ou d'autres équivalents de classes statiques) n'est probablement pas le choix de conception que vous souhaitez pour avoir un code testable et faiblement couplé. En outre, bien qu'une classe non héritable avec des membres partagés soit plus descriptive qu'un simple module, il existe au moins une circonstance où un module doit être utilisé à la place.

Quand avez-vous besoin d'utiliser des modules dans VB.Net ? Si vous voulez profiter des avantages de méthodes d'extension c'est votre seule option puisque, comme nous l'avons mentionné, vous ne pouvez pas créer de classe partagée (statique) en VB.Net, vous ne pouvez pas non plus utiliser d'extensions sur les classes non héritables. Vous devez utiliser un module comme suit :

Imports System.Runtime.CompilerServices

Public Module StringExtensions
    <Extension()> _
    Public Function Remove( _
                        ByVal input As String, _
                        ByVal subStrings As String()) As String
        Return String.Join("", input.Split(subStrings, StringSplitOptions.None)).Trim()
    End Function
End Module

En C#, vous ne pouvez pas utiliser de modules et devez utiliser des classes statiques comme suit :

public static class StringExtensions
{
    public string Remove(this string input, string[] subStrings)
    {
        return string.Join("", input.Split(subStrings, StringSplitOptions.None)).Trim();
    }
}

Answer 2

Le mot-clé Module en VB.NET provient de VB 6. En fait, il est compilé sous la forme Classe non héritable en rendant tous les membres statiques, en C# c'est comme classe scellée avec des membres statiques.

Je pense que c'est une mauvaise pratique car il n'est pas clair qu'il s'agit en fait d'une classe avec des membres statiques.

Answer 3

Il n'y a pas de problème avec les propriétés. En fait, pour mettre en œuvre la liaison, vous avez besoin de propriétés et d'implémenter l'interface INotifyPropertyChanged. Je pense que je préférerais les classes aux modules, mais je suis surtout un gars de C#.

Answer 4

Bien que cela soit possible, je dois admettre que je ne l'ai jamais vu en pratique. À mon avis, il est plus facile de lire dans une classe car cette déclaration est explicite et l'utilisation d'une classe vous permet de convertir en classe ultérieurement si le besoin s'en fait sentir. Je ne vois donc pas pourquoi vous voudriez faire cela plutôt que d'utiliser une classe avec un membre partagé.