Was ist objektorientierte Programmierung?

Klasse und Objekt

Eine Klasse ist ein Bauplan, ein Objekt eine konkrete Ausprägung davon. Die Klasse „Auto“ beschreibt Eigenschaften (Farbe, PS) und Verhalten (fahren, bremsen). Ein konkretes rotes Auto ist ein Objekt dieser Klasse.

class Auto {
  String farbe;
  void fahren() {
    System.out.println("Das Auto fährt.");
  }
}

Auto meinAuto = new Auto();
meinAuto.farbe = "rot";
meinAuto.fahren();

Die vier Säulen

• Kapselung: Daten und Verhalten bündeln, Interna verbergen
• Vererbung: Klassen erben Eigenschaften von anderen Klassen
• Polymorphie: dieselbe Methode, unterschiedliches Verhalten je Objekt
• Abstraktion: Komplexität hinter einfachen Schnittstellen verstecken

Die vier Säulen an einem Beispiel

Die objektorientierte Programmierung wird greifbar, wenn man ihre Säulen zusammen sieht. Stell dir eine Klasse „Fahrzeug“ mit der Methode fahren() vor. Ein „Auto“ und ein „Fahrrad“ erben von ihr (Vererbung), überschreiben fahren() aber jeweils eigen (Polymorphie): Beim selben Aufruf verhält sich jedes Objekt passend. Wie genau der Motor arbeitet, bleibt im Objekt verborgen — man ruft nur fahren() auf (Kapselung und Abstraktion). Wer mit dem Fahrzeug arbeitet, muss die Interna nicht kennen; das reduziert Komplexität spürbar.

Komposition statt tiefer Vererbung

Vererbung klingt verlockend, führt aber schnell zu unübersichtlichen Hierarchien, in denen eine Änderung ganz oben unerwartete Folgen ganz unten hat. Erfahrene Entwickler bevorzugen deshalb oft Komposition: Ein Objekt besitzt andere Objekte, statt von ihnen abzuleiten. Ein „Auto“ hat einen „Motor“ und vier „Räder“ — es ist kein Motor. Diese „hat ein“-Beziehung ist flexibler als eine starre „ist ein“-Kette und macht Systeme leichter änderbar.

Wann OOP die richtige Wahl ist

OOP ist kein Selbstzweck. Ihre Stärke zeigt sie bei komplexen Domänen mit vielen zusammenhängenden Dingen, die Zustand und Verhalten haben — etwa ein Shop mit Produkten, Warenkörben und Bestellungen. Für kurze Skripte oder rein datenverarbeitende Aufgaben sind funktionale oder prozedurale Ansätze oft schlanker. Gute Entwickler beherrschen mehrere Paradigmen und wählen bewusst: Die objektorientierte Programmierung ist ein mächtiges Werkzeug, aber eben eines von mehreren im Werkzeugkasten.

Sichtbarkeit steuert die Kapselung

Kapselung bleibt eine Absichtserklärung, solange von außen jeder an jedes Feld herankommt. Deshalb kennen objektorientierte Sprachen Sichtbarkeiten. Als private markierte Felder und Methoden sind nur innerhalb der Klasse selbst nutzbar, protected zusätzlich in abgeleiteten Klassen, public überall. Die bewährte Haltung lautet: so wenig öffentlich wie möglich. Was privat ist, kann jederzeit umgebaut werden, ohne dass fremder Code bricht — genau das macht eine Klasse wartbar. Wo Zugriff nötig ist, geht er über Methoden, die den Wert prüfen dürfen: Ein Kontostand lässt sich so nicht einfach auf einen unmöglichen Wert setzen.

Schnittstellen und lose Kopplung

Ein Interface beschreibt, welche Methoden eine Klasse anbieten muss, ohne festzulegen, wie sie das tut. Es ist ein Vertrag. Der Nutzen zeigt sich, sobald eine Anwendung austauschbare Teile braucht: Definiert man ein Interface „Zahlungsart“ mit der Methode belasten(), können Kreditkarte, PayPal und Rechnung es jeweils eigen umsetzen — der Bestellprozess kennt nur den Vertrag, nicht die konkrete Umsetzung. Neue Zahlungsarten kommen hinzu, ohne dass bestehender Code angefasst wird. Und beim Testen setzt man an dieselbe Stelle eine einfache Attrappe ein, statt bei jedem Testlauf echtes Geld zu bewegen.

Entwurfsmuster: wiederkehrende Lösungen

Weil sich bestimmte Entwurfsfragen immer wieder stellen, haben sich für sie benannte Standardlösungen etabliert. Eine Fabrik kapselt, welche konkrete Klasse in welcher Situation erzeugt wird. Das Beobachter-Muster erlaubt es Objekten, sich für Benachrichtigungen bei einem anderen Objekt anzumelden — das Prinzip hinter Event-Systemen. Und die Strategie tauscht austauschbare Verfahren zur Laufzeit aus, etwa verschiedene Versandkostenberechnungen. Der Nutzen liegt weniger im Code als in der gemeinsamen Sprache: Wer „das lösen wir über eine Strategie“ sagt, hat eine Struktur beschrieben, die alle im Team sofort vor Augen haben. Einsetzen sollte man Muster allerdings erst, wenn das Problem tatsächlich auftritt — nicht vorsorglich.