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 {
  today() {
    return new Date();
  }
}


const clock = new SystemClock();


const FRIDAY = 5;


class OrderService {
  price(amount) {
    if (clock.today().getDay() === FRIDAY) {
      return amount * 0.9;
    }
    return amount;
  }
}

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

const service = new OrderService();
console.log(`Freitagsrabatt: erwartet 90.00 €, bekommen ${service.price(100).toFixed(2)} €`);

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 im Konstruktor. Was das Objekt ist, spielt keine Rolle, solange es eine Methode today() hat;
  • 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 als Klasse gesehen, die ihr eines Objekt hält. In JavaScript macht man das selten so, weil die Sprache schon etwas hat, das nur einmal läuft: das Modul.Ein Modul (die Datei clock.js) läuft einmal, beim ersten import. Jedes spätere import { clock } from "./clock.js" liefert dasselbe Objekt. Ein Objekt, das ein Modul mit export herausgibt, ist ein Singleton ohne eine einzige zusätzliche Zeile Code:
class SystemClock {
  constructor() {
    console.log("Erzeuge die Uhr");
  }


  today() {
    return new Date();
  }
}


export const clock = new SystemClock();
console.log("Start");
Ausgabe
Erzeuge die Uhr
Start
Das Objekt wird erzeugt, wenn das Modul läuft, vor der ersten Zeile, die es benutzt. In diesem Programm stehen Modul und Code in einer Datei. In einem echten Projekt liegt die Uhr in einer eigenen Datei, und egal, an wie vielen Stellen sie importiert wird, es gibt ein Objekt.
Genauer, für Neugierige
Mit require (CommonJS, der älteren Art von Modulen in Node.js) ist es dasselbe: Das Modul läuft beim ersten require, und spätere bekommen sein fertiges Ergebnis.

Sieh es dir an

Die Uhr kommt von außen

Der Service verlangt im Konstruktor eine Uhr. Was sie ist, spielt keine Rolle, solange sie eine Methode today() hat. Das Modul mit clock bleibt, wie es ist:
const FRIDAY = 5;


class OrderService {
  constructor(clock) {
    this.clock = clock;
  }


  price(amount) {
    if (this.clock.today().getDay() === FRIDAY) {
      return amount * 0.9;
    }
    return amount;
  }
}

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

const service = new OrderService(clock);

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.

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 {
  constructor(date) {
    this.date = date;
  }


  today() {
    return this.date;
  }
}

Der Test reicht sie statt der echten hinein:

const clock = new FakeClock(new Date(2026, 9, 30));
const service = new OrderService(clock);
console.log(`Freitag: ${service.price(100).toFixed(2)} €`);


clock.date = new Date(2026, 9, 27);
console.log(`Dienstag: ${service.price(100).toFixed(2)} €`);
Ausgabe
Freitag: 90.00 €
Dienstag: 100.00 €

const clock = new FakeClock(new Date(2026, 9, 30));
const service = new OrderService(clock);
console.log(`Freitag: ${service.price(100).toFixed(2)} €`);


clock.date = new Date(2026, 9, 27);
console.log(`Dienstag: ${service.price(100).toFixed(2)} €`);
Schritt für Schritt, in Worten
  1. Vorher griff price selbst nach der clock auf Modulebene: 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.
Monate in Date zählen ab 0: new Date(2026, 9, 30) ist der 30. Oktober.

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
Eine Uhr mit einer Methode kann auch ein einfaches Objekt sein: { today: () => new Date(2026, 9, 30) }. Eine Klasse ist nicht nötig: Der Service braucht nur eine Methode today().

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?

const clock = new FakeClock(new Date(2026, 9, 30));
const shop = new OrderService(clock);
clock.date = new Date(2026, 9, 31);
const app = new OrderService(clock);


console.log(`${shop.price(50).toFixed(2)} €`);
console.log(`${app.price(50).toFixed(2)} €`);
Antwort

Probier es aus

Finde den Fehler

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

class Cart {
  constructor() {
    this.items = [];
  }


  add(item) {
    this.items.push(item);
  }
}


const cart = new Cart();

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

const first = new CheckoutPage();
first.add("Kaffee");
first.add("Tasse");
check("Test 1", first.count(), 2);


const 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 dem Programmanfang 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.

Ü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 der Uhr, 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 ·