C# abstrakte Klasse: abstrakte Methoden, Beispiele und vs. Interface

Eine abstrakte Klasse ist eine Klasse, die nur existiert, um von ihr abzuleiten. Sie lässt sich nicht instanziieren und kann abstrakte Member deklarieren: Methoden und Properties ohne Rumpf, die jede konkrete abgeleitete Klasse implementieren muss. Alles andere an ihr ist eine gewöhnliche Klasse: Sie kann Felder, Konstruktoren und vollständig implementierte Methoden haben, die abgeleitete Klassen erben.

Eine abstrakte Klasse deklarieren

Markiere die Klasse als abstract und jeden Member, den abgeleitete Klassen liefern müssen, ebenfalls als abstract, abgeschlossen mit einem Semikolon statt eines Rumpfs:

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'
    }
}

Ausgabe:

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

Describe wird einmal geschrieben, in der Basisklasse, und ruft Area und Perimeter auf, die es in Shape gar nicht gibt. Genau darum geht es bei einem abstrakten Member: Die Basisklasse kann sich darauf verlassen, und der Compiler garantiert, dass jede konkrete Form ihn liefert. Eine abgeleitete Klasse, die einen vergisst, kompiliert nicht:

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

Die Lösung ist, Perimeter zu implementieren oder Triangle selbst als abstract zu markieren, wenn es eine Zwischenbasis für weitere Klassen ist.

Regeln für abstrakte Member

• Ein abstrakter Member hat keinen Rumpf und ist implizit virtuell: Abgeleitete Klassen implementieren ihn mit override.
• Nur abstrakte Klassen dürfen abstrakte Member enthalten. Einen in eine normale Klasse zu setzen ist ein Kompilierfehler.
• Abstrakte Member können nicht private sein (niemand könnte sie überschreiben) und in einer Klasse nicht static.
• Methoden, Properties, Indexer und Events können abstrakt sein. Felder und Konstruktoren nicht.
• Eine abstrakte Klasse muss keinen abstrakten Member enthalten. Eine Klasse nur als abstract zu markieren verhindert die Instanziierung, nützlich für eine Basisklasse, die nur über ihre Unterklassen Sinn ergibt.

Eine abstrakte Property legt fest, welche Accessoren die abgeleitete Klasse liefern muss:

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";
}

Konstruktoren in abstrakten Klassen

Eine abstrakte Klasse kann Konstruktoren haben. Sie lassen sich nicht mit new aufrufen, aber jeder abgeleitete Konstruktor führt über : base(...) einen davon aus, sie sind also der Ort, an dem gemeinsamer Zustand initialisiert und validiert wird. Deklariere sie als protected, was genau das sagt: Nur abgeleitete Klassen können ihn verwenden.

Das Template-Method-Muster

Der häufigste Grund, eine abstrakte Klasse zu schreiben, ist, die Reihenfolge eines Algorithmus in der Basisklasse festzulegen und abgeleitete Klassen einzelne Schritte ausfüllen zu lassen. Die Basismethode, die die Schritte ausführt, ist nicht virtuell, keine Unterklasse kann sie also umordnen oder überspringen.

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");
    }
}

Ausgabe:

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

Jede Zeile ist ein benanntes Tupel, und die Ausgabe wird mit einem StringBuilder gebaut. Beachte die Mischung: Header und Row sind abstract, weil jedes Format sie festlegen muss, und Footer ist virtual mit leerem Standard, weil die meisten Formate dort nichts brauchen. Die Schritte sind protected, externer Code kann also nur Export aufrufen. Framework-Klassen nutzen dieselbe Idee: Stream und TextWriter sind abstrakte Basisklassen, deren viele Komfortmethoden auf wenigen Membern aufbauen, die eine abgeleitete Klasse liefert (Read und Write bei einem Stream, Write(char) bei einem TextWriter).

Abstrakte Klasse gegenüber Interface

Beide lassen dich Code gegen einen Typ schreiben, ohne die konkrete Klasse zu kennen. Sie unterscheiden sich darin, was sie enthalten können und wie viele eine Klasse haben kann:

Standard-Interface-Methoden (C# 8) haben den Abstand verkleinert, aber nicht den Kernunterschied:

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

Eine Standardmethode kann trotzdem keine Instanzfelder anfassen, weil das Interface keine hat; sie kann nur andere Member des Interfaces aufrufen.

Ein praktischer Weg zur Entscheidung:

• Interface, wenn du eine Fähigkeit beschreibst, die voneinander unabhängige Typen haben können (IComparable<T>, IDisposable, IShippingProvider), wenn Structs mitmachen sollen oder wenn eine Klasse mehrere solcher Rollen braucht. Der meiste Code mit Dependency Injection ist aus diesem Grund gegen Interfaces geschrieben.
• Abstrakte Klasse, wenn die abgeleiteten Typen wirklich Varianten einer Sache sind und Zustand oder einen festen Algorithmus teilen, wie die Exporter oben.
• Beides ist verbreitet: ein Interface, von dem Aufrufer abhängen, und eine abstrakte Basisklasse, die es implementiert und Implementierern das Neuschreiben der gemeinsamen Teile erspart. Die Seite zu Interfaces behandelt die Seite des Interfaces ausführlich.

Häufige Fehler

• Versuchen, die Basisklasse zu instanziieren. new Shape(...) ist CS0144. Instanziiere eine abgeleitete Klasse.
• override an der Implementierung vergessen. public double Area() in der abgeleiteten Klasse zu schreiben implementiert den abstrakten Member nicht; der Compiler meldet CS0534 für die fehlende Implementierung, plus eine Warnung, dass die neue Methode die geerbte verdeckt.
• Ein öffentlicher Konstruktor an einer abstrakten Klasse. Harmlos, aber irreführend. Nimm protected.
• Abstrakte Klassen ohne gemeinsamen Code. Hat die Basisklasse nur abstrakte Member und keinen Zustand, sagt ein Interface dasselbe und verbraucht nicht den einzigen Platz für eine Basisklasse.
• Abstrakte Member aus dem Basiskonstruktor aufrufen. Die abgeleitete Implementierung läuft vor dem Rumpf des abgeleiteten Konstruktors, Felder, die dieser Rumpf zuweist, sind also noch 0 oder null.