Zum Inhalt
wannacode

Singleton und Dependency Injection

Kurz gesagt: Singleton garantiert genau eine Instanz einer Klasse, Dependency Injection reicht Abhängigkeiten von außen hinein, damit sich der Code mit einem Ersatz testen lässt, etwa mit einer Uhr.

Problem

Der Test, der nur freitags besteht

Freitags gibt der Shop 10 % Rabatt. Das Programm hat eine Uhr, also ist sie ein Singleton: eine Klasse mit nur einem Objekt, von überall erreichbar. Der Bestell-Service fragt sie, welcher Tag heute ist:

class SystemClock
{
    public static readonly SystemClock Instance = new SystemClock();


    private SystemClock()
    {
    }


    public DateTime Today => DateTime.Today;
}


class OrderService
{
    public decimal Price(decimal amount)
    {
        if (SystemClock.Instance.Today.DayOfWeek == DayOfWeek.Friday)
        {
            return amount * 0.9m;
        }
        return amount;
    }
}

Jemand schreibt einen Test, um sicherzugehen, dass der Rabatt funktioniert:

var service = new OrderService();
Console.WriteLine($"Freitagsrabatt: erwartet 90.00 €, bekommen {service.Price(100):F2} €");

An einem Montag, dem 26. Oktober 2026, gibt der Test aus:

Ausgabe
Freitagsrabatt: erwartet 90.00 €, bekommen 100.00 €

An einem Freitag gibt derselbe Test 90.00 aus. Der Test besteht an einem Tag pro Woche und fällt an den anderen sechs durch, und der Code ist derselbe. Um den Rabatt zu prüfen, musst du auf den Freitag warten oder die Uhr des Computers verstellen.

Die Uhr selbst ist richtig gemacht. Das Problem ist, dass Price selbst nach ihr greift. Von außen siehst du nicht, dass der Service von einer Uhr abhängt: new OrderService() verlangt nichts. Der Test kann ihm keinen anderen Tag geben, weil er ihm überhaupt nichts geben kann.

Die Idee

Das eine Objekt und das Hineinreichen

Ein Singleton garantiert zwei Dinge: Es gibt nur ein Objekt, und jeder kann es von überall nehmen. Das Erste braucht man manchmal. Das Zweite ist der Preis:

  • eine versteckte Abhängigkeit. Wer die Uhr benutzt, siehst du nur, wenn du jede Zeile jeder Methode liest;
  • gemeinsamer Zustand. Was ein Stück Code im Objekt ändert, sehen alle anderen, auch der nächste Test;
  • es lässt sich nicht austauschen. Der Code verweist namentlich auf die konkrete Klasse. Eine andere Uhr für den Test hat keinen Weg hinein.

Die Lösung ist nicht, die Uhr zu entfernen, sondern sie von außen hineinzureichen. Der Service sucht seine Abhängigkeit nicht, er bekommt sie im Konstruktor. Welche Uhr es ist, entscheidet, wer den Service erzeugt: Das Programm reicht die echte hinein, der Test seine eigene, mit einem Datum, das der Test wählt.

Das heißt Dependency Injection (DI). Es gibt drei Rollen:

  • der Service sagt, was er braucht: ein Parameter mit Interface-Typ im Konstruktor;
  • die Abhängigkeit ist das Objekt, das er bekommt: die echte Uhr oder die Testuhr;
  • das Verdrahten passiert an einer Stelle, am Anfang des Programms. Dort entscheidest du, welches Objekt wohin kommt.

Der Singleton kann sogar bleiben: Die eine Uhr wird wie jedes andere Objekt hineingereicht. Nur greift niemand mehr von sich aus nach ihr.

Sieh es dir an

Singleton, so wie die Sprache ihn bietet

In der Lektion „Entwurfsmuster“ hast du einen Singleton mit if (instance == null) gesehen. Wenn zwei Threads gleichzeitig bei der Prüfung ankommen, bekommst du zwei Objekte. Die Sprache hat sicherere Wege.Die Uhr aus dem Problem steht in einem static readonly-Feld. Die Laufzeit erzeugt sie einmal, bevor die Klasse benutzt wird, und das ist auch mit vielen Threads sicher. Wenn die Erzeugung teuer ist und erst bei der ersten Anfrage passieren soll, gibt es Lazy<T>: Das Objekt entsteht beim ersten .Value, ebenfalls nur einmal:
class SystemClock
{
    private static readonly Lazy<SystemClock> instance = new Lazy<SystemClock>(() => new SystemClock());


    public static SystemClock Instance => instance.Value;


    private SystemClock()
    {
        Console.WriteLine("Erzeuge die Uhr");
    }
}
Console.WriteLine("Start");
var a = SystemClock.Instance;
var b = SystemClock.Instance;
Console.WriteLine(a == b);
Ausgabe
Start
Erzeuge die Uhr
True
Die Uhr wird erst erzeugt, wenn jemand sie verlangt, und nur einmal. Beide Variablen zeigen auf dasselbe Objekt.
Genauer, für Neugierige
static readonly und Lazy<T> schützen nur vor einer zweiten Erzeugung. Vor der versteckten Abhängigkeit schützen sie nicht: SystemClock.Instance kann weiterhin von überall aufgerufen werden.

Sieh es dir an

Die Uhr kommt von außen

Der Service verlangt eine IClock: ein Interface mit einer Property. SystemClock aus dem Problem bekommt nur ein : IClock dazu:
interface IClock
{
    DateTime Today { get; }
}


class OrderService
{
    private readonly IClock clock;


    public OrderService(IClock clock)
    {
        this.clock = clock;
    }


    public decimal Price(decimal amount)
    {
        if (clock.Today.DayOfWeek == DayOfWeek.Friday)
        {
            return amount * 0.9m;
        }
        return amount;
    }
}

Im Programm wird die echte Uhr einmal hineingereicht, bei der Erzeugung:

var service = new OrderService(SystemClock.Instance);

Jetzt sagt new OrderService(...) laut, dass er ohne Uhr nicht arbeiten kann. Die Abhängigkeit steht in der Signatur des Konstruktors, nicht irgendwo in einer Methode.

In ASP.NET Core übernimmt das Hineinreichen der Container des Frameworks. Du registrierst die Uhr einmal, builder.Services.AddSingleton<IClock>(SystemClock.Instance), und jeder Controller, der im Konstruktor eine IClock verlangt, bekommt sie. So funktioniert IProductService in den Lektionen MVC, Views mit Razor und WebAPI. AddSingleton heißt dort „ein Objekt für die ganze Anwendung“, aber niemand nimmt es sich selbst: Das Framework reicht es hinein.

Sieh es dir an

Der Test wählt den Tag selbst

Der Test braucht eine Uhr, der du sagen kannst, welches Datum sie zurückgeben soll:

class FakeClock : IClock
{
    public DateTime Today { get; set; }


    public FakeClock(DateTime today)
    {
        Today = today;
    }
}

Der Test reicht sie statt der echten hinein:

var clock = new FakeClock(new DateTime(2026, 10, 30));
var service = new OrderService(clock);
Console.WriteLine($"Freitag: {service.Price(100):F2} €");


clock.Today = new DateTime(2026, 10, 27);
Console.WriteLine($"Dienstag: {service.Price(100):F2} €");
Ausgabe
Freitag: 90.00 €
Dienstag: 100.00 €

var clock = new FakeClock(new DateTime(2026, 10, 30));
var service = new OrderService(clock);
Console.WriteLine($"Freitag: {service.Price(100):F2} €");


clock.Today = new DateTime(2026, 10, 27);
Console.WriteLine($"Dienstag: {service.Price(100):F2} €");
Schritt für Schritt, in Worten
  1. Vorher griff Price selbst nach SystemClock.Instance: eine versteckte Verbindung zu einem globalen Objekt, das der Test nicht ändern kann.
  2. Der Test baut sich eine eigene Uhr: eine FakeClock, die 2026-10-30 sagt, ein Freitag.
  3. Die Uhr kommt von außen herein, über den Konstruktor. OrderService hält nur einen Verweis auf sie.
  4. Price(100): Der Service fragt seine Uhr. Es ist Freitag, also ist der Betrag 90.00.
  5. Der Test verschiebt das Datum auf 2026-10-27, einen Dienstag. In OrderService ändert sich nichts.
  6. Dasselbe Price(100): ein Dienstag, 100.00. Der Test gibt diese beiden Zahlen an jedem Wochentag.

Der Test gibt diese beiden Zahlen an einem Montag, an einem Freitag und an einem Sonntag aus. OrderService ist dieselbe Klasse, die im Shop läuft: Der Test ändert nur, was er hineinreicht.

Genauer, für Neugierige
Seit .NET 8 gibt es die eingebaute abstrakte Klasse TimeProvider mit GetLocalNow(): Das Programm reicht TimeProvider.System hinein und die Tests ihre eigene Unterklasse. Die Idee ist dieselbe wie bei IClock.

Probier es aus

Sag die Ausgabe voraus

Die Klassen stammen von den Karten davor. Der 31. Oktober 2026 ist ein Samstag. Was gibt das Programm aus?

var clock = new FakeClock(new DateTime(2026, 10, 30));
var shop = new OrderService(clock);
clock.Today = new DateTime(2026, 10, 31);
var app = new OrderService(clock);


Console.WriteLine($"{shop.Price(50):F2} €");
Console.WriteLine($"{app.Price(50):F2} €");
Antwort

Probier es aus

Finde den Fehler

Der Warenkorb ist ein Singleton, „damit es nur einen gibt“:

class Cart
{
    public static readonly Cart Instance = new Cart();
    private readonly List<string> items = new List<string>();


    private Cart()
    {
    }


    public void Add(string item)
    {
        items.Add(item);
    }


    public int Count => items.Count;
}

Zwei Tests, jeder mit seiner eigenen Kassenseite. check gibt OK aus oder das, was der Test erwartet hat:

var first = new CheckoutPage();
first.Add("Kaffee");
first.Add("Tasse");
Check("Test 1", first.Count, 2);


var second = new CheckoutPage();
second.Add("Kaffee");
Check("Test 2", second.Count, 1);
Ausgabe
Test 1: OK
Test 2: FAIL, erwartet 1, bekommen 3

Jeder Test besteht für sich. Zusammen fällt der zweite durch. In welcher Zeile steckt der Fehler?

Wähle die Zeile mit dem Fehler.

Genauer, für Neugierige

Test-Bibliotheken führen Tests in einer nicht garantierten Reihenfolge aus, manchmal gleichzeitig. Ein Test, der nur besteht, wenn er zuerst läuft, ist ein Test, der zufällig durchfällt. Gemeinsamer Zustand in einem Singleton ist die häufigste Ursache.

Die Idee

Wann du es nicht brauchst

Ein Singleton ist sinnvoll, wenn eine zweite Kopie ein Fehler wäre und das Objekt nichts hält, das sich ändert: Einstellungen, die beim Start einmal gelesen werden, das Log, der Pool der Datenbankverbindungen. Auch dann reichst du es besser von außen hinein, als dass alle danach greifen.

Das Hineinreichen hat auch einen Preis. Es lohnt sich nicht, wenn:

  • die Abhängigkeit sich nie ändert und den Tests nicht im Weg steht. Math.Round ist keine Abhängigkeit, die du hineinreichst;
  • das Programm klein ist. Das Verdrahten von Hand in Main reicht; ein DI-Framework ist für große Anwendungen;
  • der Konstruktor acht Abhängigkeiten verlangt. Das ist kein DI-Problem: Die Klasse tut zu viel.
Ein Interface mit einer Implementierung „auf Verdacht“ ist unnötig. Hier gibt es zwei Implementierungen, die echte und die Test-Variante, und das Interface lohnt sich.

Übung

Black Friday

Löse die Aufgabe in deinem Editor.

Black Friday. Am 27. November 2026 gibt der Shop 30 % Rabatt, an anderen Freitagen weiterhin 10 %. Füge die Regel zu OrderService hinzu und prüfe sie mit FakeClock für drei Daten: Black Friday, den 30. Oktober (ein Freitag) und den 27. Oktober (ein Dienstag). Der Test gibt an jedem Tag dieselbe Ausgabe.

Ausgabe
Black Friday: 70.00 €
Freitag: 90.00 €
Dienstag: 100.00 €

Weitere Aufgaben

  • Bestellnummern. Der Zähler für Bestellnummern ist ein Singleton und beginnt bei 1001. Mach ihn zu einer Abhängigkeit von OrderService und schreibe zwei Tests, die beide 1001 als erste Nummer bekommen.
  • Ein Warenkorb pro Kunde. Behebe den Fehler aus „Finde den Fehler“ ganz: Der Warenkorb ist kein Singleton, und jede Seite bekommt ihren eigenen. Zwei Kunden legen verschiedene Artikel hinein, und jeder sieht nur seine eigenen.
  • Nachtrabatt. Zwischen 22:00 und 6:00 Uhr beträgt der Rabatt 5 %. Die Uhr muss jetzt auch die Stunde liefern. Was änderst du an IClock, und wie viele Tests brauchst du, um sicher zu sein?

Test

Teste dich

1. Warum besteht der Test für den Freitagsrabatt nur freitags?
2. Was ändert das Hineinreichen der Abhängigkeit (Dependency Injection)?
3. Zwei Tests benutzen denselben Warenkorb, ein Singleton. Der erste legt zwei Artikel hinein, der zweite einen und erwartet 1. Was passiert?
4. Wann passt ein Singleton?

Erstellt von Ivo Gergov im Rahmen der Kampagne von Evo Tech für zugängliche Programmierausbildung ·