Classe abstraite en C# : méthodes abstraites, exemples et comparaison avec les interfaces

Une classe abstraite est une classe qui n'existe que pour qu'on en dérive. Elle ne peut pas être instanciée, et elle peut déclarer des membres abstraits : des méthodes et propriétés sans corps que chaque classe dérivée concrète doit implémenter. Pour tout le reste, c'est une classe ordinaire : elle peut avoir des champs, des constructeurs et des méthodes entièrement implémentées dont héritent les classes dérivées.

Déclarer une classe abstraite

Marquez la classe abstract, et marquez abstract chaque membre que les classes dérivées doivent fournir, en le terminant par un point-virgule au lieu d'un corps :

using System;
using System.Collections.Generic;

abstract class Shape
{
    public string Label { get; }

    protected Shape(string label) { Label = label; }

    public abstract double Area();              // no body: each shape must implement it
    public abstract double Perimeter();

    public string Describe() =>                 // shared, concrete method
        $"{Label}: area {Area():F2}, perimeter {Perimeter():F2}";
}

class Circle : Shape
{
    private readonly double radius;
    public Circle(double radius) : base("Circle") { this.radius = radius; }

    public override double Area() => Math.PI * radius * radius;
    public override double Perimeter() => 2 * Math.PI * radius;
}

class Rectangle : Shape
{
    private readonly double width, height;
    public Rectangle(double w, double h) : base("Rectangle") { width = w; height = h; }

    public override double Area() => width * height;
    public override double Perimeter() => 2 * (width + height);
}

class Program
{
    static void Main()
    {
        var shapes = new List<Shape> { new Circle(1.5), new Rectangle(4, 2.5) };
        foreach (Shape s in shapes)
            Console.WriteLine(s.Describe());

        // var s2 = new Shape("blob"); // error CS0144: Cannot create an instance of the abstract type or interface 'Shape'
    }
}

Sortie :

Circle: area 7.07, perimeter 9.42
Rectangle: area 10.00, perimeter 13.00

Describe est écrite une fois, dans la classe de base, et appelle Area et Perimeter, qui n'existent pas du tout dans Shape. C'est tout l'intérêt d'un membre abstrait : la classe de base peut compter dessus, et le compilateur garantit que chaque forme concrète le fournit. Une classe dérivée qui en oublie un ne compile pas :

class Triangle : Shape
{
    public Triangle() : base("Triangle") { }
    public override double Area() => 6;
}
// error CS0534: 'Triangle' does not implement inherited abstract member 'Shape.Perimeter()'

La correction consiste à implémenter Perimeter, ou à marquer Triangle lui-même abstract s'il s'agit d'une base intermédiaire pour d'autres classes.

Règles des membres abstraits

• Un membre abstrait n'a pas de corps et est implicitement virtuel : les classes dérivées l'implémentent avec override.
• Seules les classes abstraites peuvent contenir des membres abstraits. En placer un dans une classe normale est une erreur de compilation.
• Les membres abstraits ne peuvent pas être private (personne ne pourrait les redéfinir) ni static dans une classe.
• Les méthodes, propriétés, indexeurs et événements peuvent être abstraits. Les champs et les constructeurs non.
• Une classe abstraite n'est pas obligée de contenir un membre abstrait. Marquer une classe abstract empêche simplement son instanciation, ce qui est utile pour une classe de base qui n'a de sens qu'à travers ses sous-classes.

Une propriété abstraite déclare les accesseurs que la classe dérivée doit fournir :

abstract class Plan
{
    public abstract decimal MonthlyPrice { get; }
    public abstract string Name { get; }
}

class ProPlan : Plan
{
    public override decimal MonthlyPrice => 12.99m;
    public override string Name => "Pro";
}

Constructeurs dans les classes abstraites

Une classe abstraite peut avoir des constructeurs. On ne peut pas les appeler avec new, mais chaque constructeur dérivé en exécute un via : base(...), ils sont donc l'endroit où l'état partagé est initialisé et validé. Déclarez-les protected, ce qui dit exactement cela : seules les classes dérivées peuvent l'utiliser.

Le patron de méthode

La raison la plus courante d'écrire une classe abstraite est de fixer l'ordre d'un algorithme dans la classe de base et de laisser les classes dérivées remplir chaque étape. La méthode de base qui exécute les étapes n'est pas virtuelle, donc aucune sous-classe ne peut les réordonner ou en sauter.

using System;
using System.Collections.Generic;
using System.Text;

abstract class OrderExporter
{
    // The template: the steps and their order are fixed here.
    public string Export(IEnumerable<(string Item, int Qty, decimal Price)> rows)
    {
        var sb = new StringBuilder();
        sb.Append(Header());
        decimal total = 0;
        foreach (var r in rows)
        {
            sb.Append(Row(r.Item, r.Qty, r.Price));
            total += r.Qty * r.Price;
        }
        sb.Append(Footer(total));
        return sb.ToString();
    }

    protected abstract string Header();
    protected abstract string Row(string item, int qty, decimal price);
    protected virtual string Footer(decimal total) => "";   // optional step with a default
}

class CsvExporter : OrderExporter
{
    protected override string Header() => "item,qty,price\n";
    protected override string Row(string item, int qty, decimal price) => $"{item},{qty},{price}\n";
}

class MarkdownExporter : OrderExporter
{
    protected override string Header() => "| Item | Qty | Price |\n| --- | --- | --- |\n";
    protected override string Row(string item, int qty, decimal price) => $"| {item} | {qty} | {price} |\n";
    protected override string Footer(decimal total) => $"\nTotal: {total}\n";
}

class Program
{
    static void Main()
    {
        var rows = new List<(string, int, decimal)> { ("Coffee beans", 2, 11.50m), ("Filter papers", 1, 3.20m) };

        OrderExporter[] exporters = { new CsvExporter(), new MarkdownExporter() };
        foreach (var e in exporters)
            Console.Write(e.Export(rows) + "\n");
    }
}

Sortie :

item,qty,price
Coffee beans,2,11.50
Filter papers,1,3.20

| Item | Qty | Price |
| --- | --- | --- |
| Coffee beans | 2 | 11.50 |
| Filter papers | 1 | 3.20 |

Total: 26.20

Chaque ligne est un tuple nommé, et la sortie est construite avec un StringBuilder. Remarquez le mélange : Header et Row sont abstract parce que chaque format doit les définir, et Footer est virtual avec un comportement par défaut vide parce que la plupart des formats n'ont besoin de rien à cet endroit. Les étapes sont protected, donc le code extérieur ne peut appeler que Export. Les classes du framework utilisent la même idée : Stream et TextWriter sont des classes de base abstraites dont les nombreuses méthodes pratiques reposent sur quelques membres fournis par une classe dérivée (Read et Write pour un flux, Write(char) pour un writer de texte).

Classe abstraite ou interface

Les deux permettent d'écrire du code pour un type sans connaître la classe concrète. Elles diffèrent par ce qu'elles peuvent contenir et par le nombre qu'une classe peut en avoir :

Les méthodes d'interface par défaut (C# 8) ont réduit l'écart, mais pas la différence de fond :

public interface ILogger
{
    void Write(string message);
    void Error(string message) => Write("ERROR: " + message);   // default implementation: C# 8, .NET Core 3.0+
}

Une méthode par défaut ne peut toujours pas toucher aux champs d'instance, puisque l'interface n'en a pas ; elle ne peut qu'appeler d'autres membres de l'interface.

Une façon pratique de choisir :

• Une interface quand vous décrivez une capacité que des types sans rapport peuvent avoir (IComparable<T>, IDisposable, IShippingProvider), quand des structs doivent pouvoir y participer, ou quand une classe a besoin de plusieurs rôles de ce genre. La plupart du code d'injection de dépendances est écrit pour des interfaces pour cette raison.
• Une classe abstraite quand les types dérivés sont vraiment des variantes d'une même chose et partagent un état ou un algorithme fixe, comme les exportateurs ci-dessus.
• Les deux est courant : une interface dont dépendent les appelants, et une classe de base abstraite qui l'implémente et évite aux implémenteurs de réécrire les parties communes. La page sur les interfaces couvre en détail le côté interface.

Erreurs courantes

• Essayer d'instancier la classe de base. new Shape(...) donne CS0144. Instanciez une classe dérivée.
• Oublier override sur l'implémentation. Écrire public double Area() dans la classe dérivée n'implémente pas le membre abstrait ; le compilateur signale CS0534 pour l'implémentation manquante, plus un avertissement indiquant que la nouvelle méthode masque celle héritée.
• Un constructeur public sur une classe abstraite. Sans danger, mais trompeur. Utilisez protected.
• Des classes abstraites sans code partagé. Si la classe de base n'a que des membres abstraits et aucun état, une interface dit la même chose et n'occupe pas l'unique place de classe de base.
• Appeler des membres abstraits depuis le constructeur de base. L'implémentation dérivée s'exécute avant le corps du constructeur dérivé, donc les champs que ce corps affecte valent encore 0 ou null.