Angenommen, zwei Entwicklerinnen im selben Team sollen die Preisberechnung eines Webshops neu schreiben. Die eine legt Klassen für Warenkorb, Rabatt und Versandart an, jede mit eigenen Methoden. Die andere schreibt eine Handvoll kleiner Funktionen, die einen Warenkorb entgegennehmen und einen Betrag zurückgeben, ohne irgendetwas zu verändern. Beide Lösungen funktionieren. Im Code-Review entbrennt trotzdem eine Grundsatzdebatte.

Diese Debatte zwischen objektorientierter Programmierung (OOP) und funktionaler Programmierung (FP) ist älter als die meisten, die sie heute führen. Sie wird oft mit einer Leidenschaft geführt, die mehr über Gewohnheiten verrät als über Technik. Ein nüchterner Blick zeigt: Beide Paradigmen lösen unterschiedliche Probleme, und die meisten aktuellen Sprachen erlauben ohnehin beides.

Paradigmen als Einschränkungen

Ein Programmierparadigma ist ein grundlegender Stil, Programme zu strukturieren. Der US-Softwareentwickler Robert C. Martin, bekannt als „Uncle Bob“, hat in seinem Buch Clean Architecture einen hilfreichen Gedanken formuliert: Jedes Paradigma nimmt Programmierern etwas weg, statt ihnen etwas zu geben.

• Die strukturierte Programmierung schränkt den direkten Sprung im Kontrollfluss ein, also den freien Sprung mit goto an beliebige Stellen im Code.
• Die objektorientierte Programmierung schränkt den indirekten Sprung ein. Statt Funktionszeiger frei herumzureichen, ruft man Methoden über Schnittstellen auf, und das Objekt entscheidet, welcher Code läuft.
• Die funktionale Programmierung schränkt die Zuweisung ein. Werte werden nicht nachträglich verändert, sondern neu erzeugt.

Das klingt zunächst nach Verzicht. Tatsächlich ist es der eigentliche Nutzen: Jede Einschränkung schließt eine bestimmte Art von Fehlern aus. Wer nicht beliebig springen kann, schreibt keinen Spaghetti-Code. Wer Daten nicht verändern kann, kann sie auch nicht versehentlich an einer entfernten Stelle überschreiben.

Eine Geschichte, die nicht der Reihe nach verlief

Oft wird die Entwicklung als Abfolge erzählt: erst unstrukturiert, dann strukturiert, dann objektorientiert, heute funktional. Die Daten sprechen eine andere Sprache.

• 1957 erschien FORTRAN, ohne Strukturen im heutigen Sinn, mit Sprüngen über Zeilennummern.
• 1958 begann John McCarthy mit LISP, der ersten Sprache mit stark funktionalem Charakter.
• Anfang der 1960er-Jahre entwickelten Ole-Johan Dahl und Kristen Nygaard in Oslo die Sprache Simula. Die Fassung Simula 67 führte Klassen und Objekte ein.
• 1968 veröffentlichte Edsger W. Dijkstra seinen Leserbrief „Go To Statement Considered Harmful“, der zum Ausgangspunkt der strukturierten Programmierung wurde.
• 1972 entstand am Xerox PARC die erste Version von Smalltalk, geprägt von Alan Kay.

Funktionale und objektorientierte Ideen sind also fast gleichzeitig entstanden, und beide sind älter als die strukturierte Programmierung als ausformulierte Lehre. Dass FP heute als „modern“ gilt, liegt weniger an ihrem Alter als daran, dass Mehrkernprozessoren und verteilte Systeme ihre Stärken wieder sichtbar gemacht haben.

Was Objektorientierung im Kern ausmacht

Im Unterricht wird OOP häufig über Vererbung erklärt: Ein Hund ist ein Tier, ein Pkw ist ein Fahrzeug. Alan Kay, der den Begriff „objektorientiert“ Ende der 1960er-Jahre prägte, sah das anders. In einer Mailingliste schrieb er 1998 sinngemäß, er bedauere den Begriff „Objekte“, weil er den Blick auf die kleinere Idee lenke. Die große Idee sei das Messaging, also der Austausch von Nachrichten.

Gemeint ist: Ein Objekt bekommt eine Nachricht und entscheidet selbst, wie es darauf reagiert. Der Aufrufer muss nicht wissen, mit welcher konkreten Art von Objekt er spricht. Diese Eigenschaft heißt Polymorphismus, wörtlich Vielgestaltigkeit, und sie ist der eigentliche Hebel der OOP. Ein Beispiel in TypeScript:

interface Versandart {
  kosten(gewichtKg: number): number;
}

class Paket implements Versandart {
  kosten(gewichtKg: number): number {
    return gewichtKg <= 5 ? 4.99 : 7.99;
  }
}

class Spedition implements Versandart {
  constructor(private readonly grundpreis: number) {}

  kosten(gewichtKg: number): number {
    return this.grundpreis + gewichtKg * 0.4;
  }
}

// Die Funktion kennt nur die Schnittstelle, nicht die konkrete Versandart.
function gesamtpreis(
  warenwert: number,
  gewichtKg: number,
  versand: Versandart,
): number {
  return warenwert + versand.kosten(gewichtKg);
}

Kommt eine neue Versandart hinzu, etwa ein Kurierdienst, entsteht eine neue Klasse. Die Funktion gesamtpreis bleibt unverändert. Darin liegt die Stärke der OOP: Neue Varianten lassen sich ergänzen, ohne bestehenden Code anzufassen. Vererbung ist dafür nicht nötig, und tiefe Vererbungshierarchien gelten heute eher als Risiko. Die Faustregel „Komposition vor Vererbung“, also Objekte aus kleineren Objekten zusammensetzen statt Klassen voneinander ableiten, ist in der Praxis weit verbreitet. Wie solche Grundsätze in heutigen Frontend- und Backend-Projekten aussehen, beschreibt der Beitrag zu den SOLID-Prinzipien in moderner Webentwicklung.

Hinzu kommt die Kapselung: Ein Objekt hält seinen Zustand für sich und erlaubt Änderungen nur über seine Methoden. Ein Bankkonto lässt sich dann nicht ins Minus buchen, wenn die Methode abbuchen das verhindert.

Was funktionale Programmierung im Kern ausmacht

Die funktionale Programmierung setzt auf reine Funktionen. Eine reine Funktion liefert für dieselben Eingaben immer dasselbe Ergebnis und hat keine Nebenwirkungen: Sie schreibt nicht in Datenbanken, ändert keine globalen Variablen und verändert auch ihre Eingaben nicht. Daten werden als unveränderlich behandelt. Wer etwas ändern möchte, erzeugt einen neuen Wert. Dieselbe Preisberechnung im funktionalen Stil:

type Position = { readonly preis: number; readonly menge: number };
type Warenkorb = readonly Position[];

const zwischensumme = (korb: Warenkorb): number =>
  korb.reduce((summe, p) => summe + p.preis * p.menge, 0);

// Eine Funktion, die eine Funktion zurückgibt: der Rabatt wird vorab festgelegt.
const mitRabatt =
  (prozent: number) =>
  (betrag: number): number =>
    betrag * (1 - prozent / 100);

// Der alte Warenkorb bleibt unverändert, es entsteht ein neuer.
const fuegeHinzu = (korb: Warenkorb, position: Position): Warenkorb => [
  ...korb,
  position,
];

const korb = fuegeHinzu([], { preis: 20, menge: 3 });
const endbetrag = mitRabatt(10)(zwischensumme(korb)); // 54

Drei Eigenschaften fallen auf. Erstens sind Funktionen hier Werte, die man weitergeben und zurückgeben kann, wie mitRabatt zeigt. Zweitens entstehen größere Abläufe durch Komposition: Kleine Funktionen werden hintereinandergeschaltet. Drittens ist jeder Baustein für sich testbar, ohne Testdatenbank und ohne vorbereiteten Zustand.

Natürlich braucht jedes nützliche Programm Nebenwirkungen, sonst würde es nichts speichern, anzeigen oder versenden. Funktionale Ansätze verbannen sie deshalb nicht, sondern drängen sie an den Rand. Ein verbreitetes Muster trägt den Namen „funktionaler Kern, imperative Schale“: Die Geschäftslogik besteht aus reinen Funktionen, und nur eine dünne äußere Schicht spricht mit Datenbank, Netzwerk und Benutzeroberfläche. Wie das in JavaScript-Projekten konkret aussieht, zeigt der Beitrag Funktional denken in JavaScript.

Die beiden Ansätze im direkten Vergleich

Die dritte Zeile verdient einen genaueren Blick. In der Informatik heißt dieser Zielkonflikt Expression Problem. In der objektorientierten Lösung oben ist eine neue Versandart schnell ergänzt. Soll aber jede Versandart zusätzlich eine Lieferzeit berechnen, muss jede Klasse angepasst werden. Im funktionalen Stil ist es umgekehrt: Eine neue Funktion lieferzeit lässt sich leicht schreiben, eine neue Datenvariante dagegen betrifft alle bestehenden Funktionen. Keine Seite gewinnt pauschal. Es kommt darauf an, was sich in Ihrem System häufiger ändert: die Arten von Dingen oder die Dinge, die man mit ihnen tut.

Auch beim Laufzeitverhalten gibt es keine einfache Antwort. Unveränderliche Daten erzeugen Kopien. Funktionale Sprachen und Bibliotheken mildern das durch Datenstrukturen, die unveränderte Teile gemeinsam nutzen, statt alles zu kopieren. Bei sehr großen Datenmengen in engen Schleifen kann veränderlicher Code dennoch schneller sein.

Denkweise und Lesbarkeit

In der Debatte taucht regelmäßig ein Argument auf: OOP entspreche dem menschlichen Denken besser, weil Menschen die Welt in Dinge und Kategorien einteilen. Funktionales Denken sei dagegen mathematisch und deshalb für viele schwerer zugänglich. Als Bild dient das Ballfangen. Niemand berechnet die Flugbahn, man fängt intuitiv.

An diesem Argument ist etwas dran, aber es greift zu kurz. Was als „natürlich“ empfunden wird, hängt stark von der Gewohnheit ab. Wer jahrelang Java geschrieben hat, liest eine Klassenstruktur schneller als eine Kette aus map, filter und reduce. Wer mit Tabellenkalkulationen arbeitet, denkt dagegen bereits funktional, denn eine Formel in einer Zelle berechnet einen Wert aus anderen, ohne sie zu verändern. Außerdem modellieren Klassen die reale Welt seltener, als Lehrbücher suggerieren. Eine Klasse RechnungsExportService hat kein Vorbild im Büro.

Entscheidend ist ein anderer Punkt: In beiden Paradigmen lässt sich guter und schlechter Code schreiben. Ein Gestrüpp aus abstrakten Basisklassen ist ebenso schwer zu verstehen wie eine Funktion, die fünf andere Funktionen als Parameter erwartet. Für die Lesbarkeit zählen klare Namen, kleine Einheiten und nachvollziehbare Datenflüsse mehr als die Wahl des Paradigmas.

Moderne Sprachen verbinden beide Welten

Die reine Lehre spielt im Alltag kaum noch eine Rolle. Fast alle verbreiteten Sprachen sind heute Mischformen.

• Java erhielt 2014 mit Version 8 Lambdas und Streams. Später kamen Records für unveränderliche Datenklassen (Java 16), versiegelte Klassen (Java 17) und Pattern Matching für switch (Java 21) hinzu.
• C# bietet mit LINQ seit Langem funktionale Abfragen und seit C# 9 Records.
• Kotlin und Scala wurden von Anfang an als objektorientiert und funktional zugleich entworfen. Wie sich Scala gegen das modernisierte Java behauptet, beschreibt der Beitrag Scala und Java: funktional und objektorientiert auf der JVM.
• TypeScript und JavaScript kombinieren Klassen mit Funktionen als Werten. React etwa setzt seit der Einführung der Hooks stark auf Funktionskomponenten.
• Rust kennt keine Vererbung, bietet aber Traits für Polymorphismus und ist sehr bewusst im Umgang mit veränderlichen Daten.

Wie nah sich die Lager inzwischen gekommen sind, zeigt die Versandberechnung in modernem Java. Records und ein versiegeltes Interface beschreiben die Daten, ein switch mit Pattern Matching die Operation:

sealed interface Versand permits Paket, Spedition {}

record Paket(double gewichtKg) implements Versand {}

record Spedition(double gewichtKg, double grundpreis) implements Versand {}

final class Versandkosten {
    static double kosten(Versand versand) {
        return switch (versand) {
            case Paket p when p.gewichtKg() <= 5 -> 4.99;
            case Paket p -> 7.99;
            case Spedition s -> s.grundpreis() + s.gewichtKg() * 0.4;
        };
    }
}

Das ist die funktionale Seite des Expression Problems, mitten in einer objektorientierten Sprache. Weil das Interface versiegelt ist, kennt der Compiler alle Varianten und meldet einen Fehler, wenn im switch eine fehlt. Kommt eine neue Versandart hinzu, zeigt er also jede Stelle an, die angepasst werden muss.

Nachrichten und Nebenläufigkeit: das Erbe von Alan Kay

Robert C. Martin hält es für wahrscheinlich, dass es nach den drei genannten keine weiteren Paradigmen gibt, weil kaum noch etwas übrig sei, was man Programmierern wegnehmen könne. Dagegen lässt sich einwenden, dass eine vierte Einschränkung längst in Gebrauch ist: der Verzicht auf synchrone Aufrufe und geteilten Zustand.

Im Aktorenmodell, das Carl Hewitt 1973 beschrieb, besteht ein System aus unabhängigen Einheiten, die ausschließlich Nachrichten austauschen. Eine Antwort kommt, wenn überhaupt, als eigene Nachricht zu einem späteren Zeitpunkt. Kein Aktor greift auf den Zustand eines anderen zu. Die Sprache Erlang, ursprünglich für Telefonvermittlungen entwickelt, baut darauf auf, ebenso Frameworks wie Akka auf der JVM. Auch das „Reactive Manifesto“ von 2014, das Antwortbereitschaft, Widerstandsfähigkeit, Elastizität und nachrichtenbasierte Kommunikation fordert, folgt dieser Linie.

Bemerkenswert ist, wie nah das an Alan Kays ursprünglicher Vorstellung von Objekten liegt, die einander Nachrichten schicken. Mit async und await in JavaScript oder C# hat das nur am Rand zu tun. Diese Schlüsselwörter machen asynchronen Code lesbarer, ändern aber nichts daran, dass Komponenten oft direkt aufeinander zugreifen. Für verteilte Systeme mit vielen Diensten ist die Idee der Nachricht dennoch zentral, etwa bei Message-Queues und ereignisgesteuerten Architekturen.

Was das für Ihr Team bedeutet

Die Frage „OOP oder FP?“ ist für die meisten Teams falsch gestellt. Sinnvoller ist es, gezielt einzelne Einschränkungen zu übernehmen, die zu den eigenen Problemen passen.

Für die meisten Geschäftsanwendungen hat sich eine Mischung bewährt: Unveränderliche Datenobjekte für Werte wie Beträge, Adressen oder Bestellpositionen, reine Funktionen für Berechnungen und Regeln, und Objekte mit klaren Schnittstellen dort, wo Varianten austauschbar sein sollen, etwa bei Zahlungsanbietern oder Speicherorten. Nebenwirkungen gehören an den Rand des Systems. Das allein beseitigt einen großen Teil der Fehler, die durch unerwartet veränderten Zustand entstehen.

Überschätzt wird dagegen der Nutzen eines Paradigmenwechsels als Ganzes. Ein Team, das von heute auf morgen streng funktional schreiben soll, läuft Gefahr, zunächst schwer lesbaren Code zu produzieren. Kleine Schritte bringen mehr: readonly und unveränderliche Typen einführen, Berechnungen aus Klassen herauslösen und testen, Vererbungshierarchien durch Komposition ersetzen. Wer TypeScript einsetzt und solche Regeln verbindlich im Team verankern möchte, findet auf der Themenseite Code-Qualität mit TypeScript Beratung und Seminare zu Typisierung, Codestandards und Refactoring.

Häufige Fragen zu OOP und funktionaler Programmierung

Was ist der größte praktische Unterschied im Entwickleralltag?

Der Umgang mit Zustand. In objektorientiertem Code stellt sich beim Debuggen oft die Frage, wer ein Objekt wann verändert hat. In funktionalem Code ist diese Frage meist schnell beantwortet, weil Werte sich nicht ändern. Dafür muss man dort nachvollziehen, durch welche Kette von Funktionen ein Wert gelaufen ist.

Für welche Projekte eignet sich funktionale Programmierung besonders?

Für alles, was im Kern Daten umformt: Berechnungen, Datenpipelines, Validierungen, Regelwerke und Systeme mit viel Nebenläufigkeit. Auch Benutzeroberflächen profitieren, wie das Beispiel React zeigt. Weniger natürlich wirkt der funktionale Stil bei Code, der hauptsächlich mit der Außenwelt spricht, etwa bei Gerätetreibern oder stark zustandsbehafteten Simulationen.

Braucht man eine funktionale Sprache, um funktional zu programmieren?

Nein. Die wichtigsten Ideen, also reine Funktionen, unveränderliche Daten und Komposition, lassen sich in Java, C#, Kotlin, Python oder TypeScript umsetzen. Eine rein funktionale Sprache wie Haskell zu lernen, kann trotzdem lohnen, weil sie zwingt, die Konzepte konsequent anzuwenden. Viele Entwicklerinnen und Entwickler schreiben danach auch in ihrer Hauptsprache anders.

Ist Vererbung heute schlechter Stil?

Nicht grundsätzlich, aber sie wird sparsamer eingesetzt als früher. Flache Hierarchien, etwa eine abstrakte Basisklasse mit wenigen Ableitungen, sind unproblematisch. Schwierig werden tiefe Hierarchien, in denen eine Änderung an der Basisklasse unerwartet viele Stellen betrifft. Schnittstellen und Komposition sind in solchen Fällen meist die flexiblere Wahl.