Les variables statiques et les méthodes C# sont-elles diaboliques ? Derek Comartin l'explique (décomposition vidéo)

Qu'est-ce qui rend une méthode statique problématique?

Au début de la vidéo, Derek se penche sur une méthode statique appelée Is18YearsOrOlder. Cette méthode prend une DateTime birthDate et vérifie si une personne a au moins 18 ans. Elle utilise DateTime.UtcNow pour comparer la date actuelle. C'est assez simple, non ?

Mais comme le souligne Derek, cette méthode n'est pas déterministe. À 0:50, il souligne que l'utilisation de DateTime.UtcNow signifie que la méthode renverra des résultats différents selon le moment où vous l'exécutez. Il s'agit d'un problème majeur dans les tests unitaires, qui entraîne des comportements inattendus dans le code.

Dans ce cas, bien que la méthode ressemble à une fonction pure, ce n'est pas le cas. Derek explique qu'une méthode pure doit renvoyer la même valeur chaque fois qu'elle est appelée avec les mêmes paramètres. Mais ici, la date actuelle ne cesse de changer, et la valeur de retour fait de même.

Ceci illustre comment une méthode statique publique, bien que pratique, peut introduire des effets secondaires si elle dépend de données en temps réel ou de l'état du domaine d'application.

Rendre les méthodes statiques testables et prévisibles

Le point suivant de Derek est crucial : nous pouvons corriger le non-déterminisme en supprimant la dépendance à DateTime.UtcNow. Au lieu de cela, Derek montre comment injecter un fournisseur de temps à l'aide d'une classe statique ou d'une implémentation d'interface. Cela rend la fonction déterministe - vous obtenez la même sortie chaque fois que vous passez la même entrée.

Dans sa classe PlaceOrder, il introduit un faux fournisseur de date afin de pouvoir tester si les commandes traitées le vendredi bénéficient d'une remise de 50 %. Cela permet d'éviter de coder en dur la logique liée au temps système, ce qui rend la méthode plus fiable et plus facile à tester.

En isolant le comportement et en évitant de référencer des méthodes statiques directement dans la logique métier, Derek montre comment préserver un code propre tout en conservant la testabilité.

Couplage étroit et méthodes statiques

Derek prévient à ce stade que le fait de s'appuyer sur des méthodes statiques introduit souvent un couplage étroit. Si vous utilisez directement DateTime.UtcNow, vous êtes lié à cette implémentation - vous ne pouvez pas la surcharger ou la simuler.

Il s'agit d'un problème car les membres statiques comme celui-ci sont globaux dans l'ensemble de votre application. Si votre base de code utilise massivement des champs statiques ou des propriétés statiques, il devient plus difficile de modifier le comportement ou d'injecter des dépendances, ce qui enfreint les principes clés de la programmation orientée objet.

Vous perdez également en flexibilité car vous ne pouvez pas remplacer ce champ statique par une implémentation différente, comme vous pourriez le faire avec une variable d'instance ou un service injecté.

Le problème de l'état global avec les variables statiques

Derek s'intéresse maintenant aux variables statiques, et c'est là que la conversation devient sérieuse.

Il présente un exemple utilisant un cache statique dans une classe Global. Il explique que le plus gros problème avec les variables statiques est l'état inconnu. Au moment de l'exécution, vous ne pouvez pas être sûr que votre champ statique a été initialisé. Cette imprévisibilité est particulièrement risquée lorsqu'il s'agit d'un nom statique mutable ou d'une chaîne de caractères.

Ce scénario s'aggrave lorsque les développeurs supposent qu'il n'y a qu'une seule copie de cette variable partagée entre les threads - et oublient de prendre en compte la sécurité des threads.

Sécurité des threads et champs statiques dans le code multithread

Derek soulève un autre problème : l'utilisation de variables statiques dans des environnements multithread. Il donne l'exemple d'une liste statique List utilisée simultanément avec Parallel.For. Le code se bloque parce que le champ statique n'est pas sécurisé pour les threads.

Pour résoudre ce problème, il adopte un ConcurrentBag, une collection thread-safe disponible dans .NET. Cela permet un accès sécurisé aux données statiques à travers plusieurs threads.

Son point de vue est clair : si vous utilisez des variables statiques dans plusieurs threads, assurez-vous qu'elles sont sûres pour les threads. Dans le cas contraire, votre programme risque de se comporter de manière imprévisible, voire de se bloquer.

Utilisation sûre des méthodes statiques

Derek partage ensuite une utilisation sûre et efficace d'une méthode statique : une simple méthode utilitaire MilesToKilometers. Il prend un miles int et renvoie une valeur double après conversion. Cette méthode est déterministe - pour la même valeur int, vous obtenez toujours le même résultat.

Ce type de méthode ne repose pas sur des champs non statiques, ne modifie pas les données partagées et n'implique pas d'état inconnu. C'est un excellent exemple de la façon d'utiliser correctement le mot-clé static en C#.

Compréhension de la statique dans le contexte .NET

En C#, le mot-clé static peut être appliqué aux classes, aux champs, aux méthodes, aux constructeurs et aux propriétés. Derek aborde indirectement le concept de :

• Classe statique : Une classe qui ne peut pas être instanciée et qui ne peut contenir que des membres statiques.

• Champs statiques : Déclarés avec le mot-clé static - une seule copie existe par domaine d'application.

• Constructeur statique : Il ne s'exécute qu'une seule fois lors du premier accès à la classe.

• Static void Main : Le point d'entrée de la plupart des applications C#, démontrant comment les méthodes statiques peuvent être essentielles.

• Static int, static string : Exemples de champs statiques qui stockent des données communes à toutes les instances de la classe ou qui, en fait, ne nécessitent pas d'instance du tout.

Contrairement aux constructeurs d'instance qui s'exécutent à chaque fois que vous créez un objet, le constructeur statique n'initialise qu'une seule fois les ressources au niveau de la classe.

Cette distinction aide les développeurs à décider quand utiliser une variable d'instance par rapport à une variable statique, ou quand utiliser des accesseurs de propriété pour encapsuler des variables membres partagées.

Témoignages finaux de Derek

Derek résume les principales raisons pour lesquelles les développeurs se méfient des membres statiques :

• Couplage étroit - vous êtes bloqué par le comportement de cette méthode ou de ce champ statique.

• Comportement non déterministe - difficile à tester, facile à casser.

• État mutable global - vous ne savez pas quelle est la valeur ni qui l'a modifiée.

• Problèmes de simultanéité - accès non sécurisé à des données partagées dans un code multithread.

Cependant, comme le dit Derek, la statique n'est pas un mal. Il est puissant lorsqu'il est utilisé correctement - en particulier dans les fonctions utilitaires, les constantes partagées ou les paramètres véritablement globaux. Il suffit de gérer l'état avec soin et d'éviter de dépendre d'un comportement mutable ou spécifique au système.

Conclusion

Les variables statiques et les méthodes sont une arme à double tranchant en C#. Comme l'explique clairement Derek Comartin, ces outils ne sont pas mauvais en soi, mais ils nécessitent une utilisation réfléchie. Utilisez des champs statiques et des classes statiques lorsque vous avez besoin de données partagées ou de fonctionnalités qui ne dépendent pas de l'état de l'objet. Mais évitez de les utiliser pour des choses qui dépendent du temps, de l'état du système ou qui requièrent de la flexibilité.

Avant de créer un objet ou d'accéder à un champ statique, réfléchissez à la portée, à la testabilité, à la sécurité des threads et à la question de savoir si le code a besoin d'une copie ou de plusieurs instances.

Regardez l'intégralité de la vidéo de Derek Martin sur sa chaîne YouTube CodeOpinion. Vous trouverez davantage d'informations sur l'architecture propre, la conception de logiciels et les applications C# du monde réel.