En C#, "class static"

août 04, 2025 Informatique

En C#, une classe static (statique) est une classe qui ne peut pas être instanciée et dont tous les membres doivent également être statiques. Elle est souvent utilisée pour contenir des méthodes utilitaires, des constantes, ou des fonctions qui ne dépendent pas de l’état d’un objet.

🔧 Définition de base

public static class MathUtils
{
    public static int Add(int a, int b)
    {
        return a + b;
    }

    public static double Square(double x)
    {
        return x * x;
    }
}

🧠 Caractéristiques importantes

✅ Exemple d’utilisation

int result = MathUtils.Add(3, 5); // retourne 8
double square = MathUtils.Square(4); // retourne 16

❌ Ce qu’on ne peut pas faire

MathUtils utils = new MathUtils(); // Erreur : impossible d’instancier une classe statique

📌 À quoi ça sert ?

• Grouper des méthodes utilitaires sans avoir besoin d’une instance

• Travailler avec des constantes globales

• Organiser du code de manière claire quand il ne dépend pas de données internes

Exemple typique dans .NET

double x = Math.Sqrt(16); // Math est une classe static fournie par .NET

Comparons une classe normale et une classe static avec un exemple simple : une calculatrice.

🔹 1. Classe normale

Cette classe peut être instanciée, elle garde un état (par exemple, un historique des calculs si tu veux).

public class Calculatrice
{
    public int DernierResultat { get; private set; }

    public int Additionner(int a, int b)
    {
        DernierResultat = a + b;
        return DernierResultat;
    }
}

📌 Utilisation :

Calculatrice calc = new Calculatrice();
int resultat = calc.Additionner(2, 3);  // resultat = 5
int dernier = calc.DernierResultat;    // dernier = 5

➡️ Ici, tu peux conserver un état (DernierResultat), car l’objet existe en mémoire.

🔹 2. Classe statique

Pas d’état, pas d’objet, juste des méthodes directes.

public static class CalculatriceStatique
{
    public static int Additionner(int a, int b)
    {
        return a + b;
    }
}

📌 Utilisation :

int resultat = CalculatriceStatique.Additionner(2, 3); // resultat = 5

➡️ Tu ne peux pas faire new CalculatriceStatique(). Tu appelles simplement la méthode.

⚖️ Comparaison rapide

Les classes static ont des avantages (simplicité, pas besoin d'instanciation), mais elles ont aussi plusieurs inconvénients importants selon le contexte.

⚠️ Inconvénients d’une classe static :

1. ❌ Pas d’héritage ni d’interface

Tu ne peux pas hériter d'une classe static, ni implémenter une interface.

public static class MonService : IService // ❌ Erreur

➡️ Donc impossible de faire du polymorphisme, ce qui est un gros frein en programmation orientée objet.

2. ❌ Pas d’état contrôlé ou d’instance isolée

Impossible d’avoir plusieurs versions isolées de la classe avec leur propre état (par exemple, plusieurs calculatrices avec historique distinct).

➡️ Toute la logique est globale, ce qui peut poser problème dans certaines architectures (comme les applications multi-utilisateurs ou multi-threads).

3. 🔒 Moins flexible pour les tests unitaires

Les classes static sont difficiles à "mock" ou remplacer dans les tests, car leurs méthodes sont directement appelées et ne peuvent pas être remplacées par des faux (mocking).

// difficile à tester :
var result = CalculatriceStatique.Additionner(2, 3);

➡️ Une classe normale peut être injectée (via DI, injection de dépendances), une classe statique non.

4. 🔄 Problèmes de dépendance globale

Une classe static peut devenir une sorte de dépendance globale cachée, ce qui crée un couplage fort entre tes classes.

➡️ Cela rend ton code moins maintenable et plus fragile à long terme.

5. 🧵 Problèmes en environnement multi-thread

Si une classe static contient des variables static modifiables (champ static), tu risques d’avoir des conflits d’accès en environnement multi-thread, à moins de gérer manuellement la synchronisation.

✅ Quand même les utiliser ?

Utilise les classes static pour :

• Des méthodes purement utilitaires, sans état (ex : Math, Convert, File, etc.)

• Des constants ou des helpers globaux

• Des outils très simples qui ne dépendent pas du contexte ou d’un utilisateur

Sur un gros projet ou une architecture propre (clean architecture, DDD…), privilégie plutôt les interfaces + injection de dépendances pour la testabilité et la flexibilité.

Voici une liste claire des bugs possibles associés aux méthodes static en C#, avec des exemples quand c'est pertinent. Même si les méthodes statiques sont souvent sûres quand elles sont pures (sans état), elles peuvent causer des bugs subtils dans certains cas.

🐛 1. Partage d’état involontaire (via variables static)

🔥 Bug :

Si une méthode statique lit/écrit dans un champ static, cet état est partagé entre tous les appels et tous les threads.

public static class Compteur
{
    private static int total = 0;

    public static void Incremente()
    {
        total++;
    }

    public static int GetTotal() => total;
}

📉 Problème :

• Accès concurrent sans protection → conditions de course (race condition)

• Résultats inattendus si plusieurs appels viennent en même temps

✅ Solution :

• Éviter tout champ static mutable

• Ou utiliser des verrous (lock) ou types thread-safe (ex: Interlocked, ConcurrentDictionary, etc.)

🐛 2. Impossible à "mock" → tests peu fiables

🔥 Bug :

Tu ne peux pas remplacer une méthode static dans un test unitaire → difficile de simuler un comportement.

public static class ServiceStatique
{
    public static bool EstConnecteInternet() => true; // dur à simuler en test
}

📉 Problème :

• Pas possible de simuler un scénario sans connexion

• Forçage de comportements pendant les tests → mauvais tests

✅ Solution :

• Utiliser des interfaces injectables à la place (ex: INetworkService)

🐛 3. Ordre d’initialisation statique

🔥 Bug :

Les membres statiques sont initialisés une seule fois quand la classe est chargée. Si l’ordre d’initialisation est mal géré → bugs mystérieux.

public static class Config
{
    public static readonly string AppName = GetConfig();

    static string GetConfig()
    {
        // Peut échouer si dépend d’un fichier non encore chargé
        return File.ReadAllText("config.txt");
    }
}

📉 Problème :

• Exception au moment de la lecture

• Mauvais état initial (valeur null ou vide)

🐛 4. Dépendance globale invisible (couplage fort)

🔥 Bug :

Une méthode statique fait appel à une autre classe statique (logging, config, service, etc.).

public static class MonService
{
    public static void FaireAction()
    {
        Logger.Log("Action en cours");  // dépendance implicite
    }
}

📉 Problème :

• Code moins lisible, plus difficile à refactorer

• Impossible de remplacer ou réorienter le comportement sans toucher au code source

🐛 5. Risque d’appel involontaire concurrent

🔥 Bug :

Méthode static appelée dans un environnement multi-thread (web server, background jobs, etc.), alors qu’elle modifie des données partagées.

public static class MonCache
{
    private static Dictionary<string, string> data = new();

    public static void Ajouter(string key, string val)
    {
        data[key] = val; // ❌ Pas thread-safe
    }
}

📉 Problème :

• Peut causer des exceptions ou des corruptions de données

• Difficile à diagnostiquer : bug aléatoire et non reproductible facilement

🐛 6. Faible testabilité, fort couplage à l'environnement

🔥 Bug :

Une méthode static interagit directement avec l’environnement (ex : disque, internet, base de données).

public static void SauvegarderTexte(string texte)
{
    File.WriteAllText("save.txt", texte);
}

📉 Problème :

• Ne fonctionne pas en environnement restreint (sandbox, test, CI/CD)

• Peut écraser des fichiers ou causer des erreurs système

✅ Résumé des bonnes pratiques :