Objektorientierte Programmierung

Objektorientierung ist eine Art, Programme zu ordnen — nicht die einzige. Die prozedurale Sichtweise beschreibt einen Ablauf aus Anweisungen und Funktionen. Die funktionale Sichtweise setzt auf unveränderliche Daten und Funktionen ohne Nebenwirkungen. Die objektorientierte Sichtweise bündelt Daten und die zugehörigen Operationen in Objekten, die sich gegenseitig Nachrichten schicken.

Die meisten heute verbreiteten Sprachen sind Mehrparadigmensprachen. Java und C# sind objektorientiert geprägt, kennen aber funktionale Ausdrücke; Python und JavaScript erlauben alle drei Stile nebeneinander. Praktisch heißt das: Man wählt nicht ein Lager, sondern pro Problem das passende Werkzeug. Datenverarbeitung liest sich funktional oft klarer, ein Domänenmodell mit Regeln und Zuständen dagegen objektorientiert.

Wichtig für Einsteiger: Objektorientierung ist kein Qualitätssiegel. Klassen, die nur Daten halten, und Methoden, die nichts kapseln, bringen keinen Vorteil — nur mehr Dateien.

Die eigentliche Kunst liegt nicht darin, Klassen zu schreiben, sondern Verantwortlichkeiten zu schneiden. Eine gute Klasse hat einen klaren Zweck, verbirgt ihren inneren Zustand und bietet nach außen eine kleine, verständliche Menge an Operationen an. Wer nur die Datenfelder öffentlich macht und für jedes davon Setz- und Lesemethoden anlegt, hat die Kapselung genau nicht erreicht.

Besonders häufig missverstanden wird die Vererbung. Sie ist die stärkste denkbare Bindung zwischen zwei Klassen und sollte nur dort stehen, wo eine echte Ist-ein-Beziehung besteht und die Oberklasse ohne Wissen über ihre Unterklassen funktioniert. Für Wiederverwendung von Verhalten ist Komposition — ein Objekt benutzt ein anderes — fast immer die flexiblere Wahl.

Als Orientierung dienen die SOLID-Prinzipien, allen voran das Prinzip der einzigen Verantwortung und die Abhängigkeitsumkehr: Programmiere gegen Abstraktionen statt gegen konkrete Implementierungen. Das macht Teile austauschbar und erleichtert Tests erheblich, weil sich Abhängigkeiten durch einfache Attrappen ersetzen lassen.

Auch wer nie bewusst objektorientiert entwirft, arbeitet ständig mit dem Modell. Frameworks der Java- und .NET-Welt sind vollständig darauf aufgebaut. In Spiel-Engines sind Szenenobjekte, Komponenten und Verhalten das zentrale Ordnungsprinzip. Selbst im Browser ist das Dokument ein Baum aus Objekten mit Eigenschaften und Methoden.

JavaScript nimmt dabei eine Sonderrolle ein: Es ist objektorientiert, aber prototypbasiert. Objekte erben direkt von anderen Objekten; die Klassenschreibweise ist eine bequeme Hülle über diesem Mechanismus. Wer das weiß, versteht das Verhalten von Vererbungsketten dort deutlich besser.

Für den Einstieg empfiehlt sich, ein überschaubares Fachthema zu modellieren, das du kennst — eine Bibliotheksausleihe, ein Turnierplan, ein Warenkorb. An echten Regeln zeigt sich schnell, welche Objekte gebraucht werden und welche Beziehungen wirklich bestehen. Danach lohnt der Blick auf klassische Entwurfsmuster, die typische Situationen benennen, statt sie neu erfinden zu müssen.

Einige Muster tauchen in objektorientiertem Code so regelmäßig auf, dass sie eigene Namen tragen. Die Gott-Klasse zieht immer mehr Aufgaben an sich, bis niemand sie mehr gefahrlos ändern kann; erkennbar ist sie an Namen wie Manager, Helper oder Utils und daran, dass sie bei jeder neuen Anforderung angefasst werden muss. Das Gegenstück ist das blutarme Modell: Klassen, die nur Daten transportieren, während sämtliche Regeln in weit entfernten Dienstklassen liegen — formal objektorientiert, inhaltlich aber eine prozedurale Lösung mit mehr Dateien.

Ebenso verbreitet sind Vererbungsketten über mehrere Ebenen, bei denen sich nicht mehr sagen lässt, wo ein Verhalten eigentlich entsteht. Und schließlich versteckte Abhängigkeiten: Eine Klasse, die sich ihre Mitarbeiter selbst beschafft — etwa über global verfügbare Einzelinstanzen —, lässt sich weder isoliert prüfen noch in einem anderen Zusammenhang wiederverwenden. Werden Abhängigkeiten stattdessen von außen übergeben, wird beides möglich, und nebenbei wird an der Signatur sichtbar, was ein Objekt überhaupt benötigt.