Objektorientierte Programmierung (OOP)

Als Agile Coach schaust du nicht auf OOP als “Technikthema”, sondern als Systemhebel

Klarheit: Kann das Team Code lesen wie eine verständliche Geschichte?

Änderbarkeit: Wie viele Stellen müssen wir anfassen, wenn sich eine Regel ändert?

Zusammenarbeit: Können mehrere Menschen parallel arbeiten, ohne sich dauernd gegenseitig zu blockieren?

Feedback: Wie schnell sehen wir, ob eine Änderung funktioniert (Tests, lokale Builds, CI)?

OOP ist hier eine Form von gemeinsamer Strukturarbeit: Sie macht Abhängigkeiten sichtbar, kapselt Variabilität und ermöglicht kleine, sichere Schritte.

OOP in einem Satz und das gemeinsame Vokabular im Team

OOP bedeutet: Wir organisieren Software als Objekte, die Verantwortung tragen, sie kapseln Daten und Verhalten und sprechen über klare Schnittstellen miteinander. Wichtig ist weniger die Theorie, sondern ein gemeinsames Vokabular

Objekt: eine Instanz mit Zustand (Daten) und Verhalten (Methoden).

Klasse: der Bauplan für Objekte.

Methode: Verhalten, das ein Objekt anbietet.

Schnittstelle / Interface: ein Vertrag, was etwas kann, ohne festzulegen, wie.

Abhängigkeit: wenn A etwas über B wissen oder B aufrufen muss.

Kapselung: Details verstecken, nur Notwendiges nach außen zeigen.

Coaching-Hinweis

Viele Konflikte in Teams starten als Sprachkonflikte (“Service”, “Manager”, “Handler”, was bedeutet das bei uns?). Ein kurzer Workshop, der Begriffe klärt, ist oft der schnellste Gewinn.

Die vier Grundpfeiler – Die Prinzipien

Kapselung (Encapsulation)

Idee: Ein Objekt schützt seinen Zustand. Andere dürfen ihn nicht beliebig verändern, sondern nur über sinnvolle Operationen.

Nutzen im agilen Alltag: Änderungen bleiben lokal: Regeln ändern sich, aber nur in einer klaren Stelle. Nebenwirkungen sinken: weniger “wer hat hier was kaputt gemacht?”

Anti-Pattern: “öffentliche Felder” oder überall Setter, wodurch jedes Objekt von außen verbogen werden kann.

Coach-Intervention (Leitfrage): “Welche Regeln sollen immer gelten, und wo wird das im Code erzwungen?”

Abstraktion (Abstraction)

Idee: Wir zeigen nur das Wesentliche, Details bleiben intern. Abstraktion ist das Weglassen von Unwichtigem.

Nutzen: Teams denken in Domänenbegriffen statt in Technikdetails. Die Komplexität wird handhabbar.

Anti-Pattern: “Abstraktion um der Abstraktion willen” (drei Schichten Interfaces ohne echten Wechselbedarf).

Coach-Intervention: “Welche Variation erwarten wir realistisch in den nächsten 2–3 Sprints?”

Vererbung (Inheritance)

Idee: Eine Klasse übernimmt Verhalten und Struktur einer anderen (“ist-ein”).

Nutzen: Kann Wiederverwendung und Polymorphie ermöglichen.

Risiken (häufig!): Starre Hierarchien, die Änderungen erschweren. Vererbung wird als “Code-Duplizierung vermeiden” missbraucht

Coach-Intervention: “Ist das wirklich ein ist-ein – oder eher ein hat-ein?” Oft ist Komposition besser: Dinge werden zusammengebaut statt abgeleitet.

Polymorphie (Polymorphism)

Idee: Unterschiedliche Implementierungen können über denselben Vertrag genutzt werden.

Nutzen: Austauschbarkeit (z. B. Zahlungsarten, Versandarten). Testbarkeit (Fake-Implementierungen). Entkopplung (Teams können unabhängig arbeiten).

Coach-Intervention: “Wo brauchen wir bewusst Variabilität – und wie machen wir sie austauschbar?

Von Features zu Objekten: Domäne, Verantwortlichkeiten, Grenzen

Agile Teams starten mit User Stories. OOP hilft, aus diesen Stories ein stabiles Modell abzuleiten.

Mini-Heuristik*: “Wörter finden”

Nimm eine User Story: “Als Kund:in möchte ich meine Bestellung bezahlen, damit sie versendet werden kann.”

Markiere Substantive und Verben: Substantive: Bestellung, Zahlung, Versand
Verben: bezahlen, versenden

Das sind Kandidaten für Objekte/Verantwortlichkeiten.

Verantwortlichkeiten statt Klassen-Sammelsurium

“Eine Klasse ist dann gut, wenn du in einem Satz sagen kannst, wofür sie verantwortlich ist.”

Beispiele:
Order ist verantwortlich für den Lebenszyklus einer Bestellung.
Payment ist verantwortlich für Zahlungszustand und Zahlungsreferenzen.
PaymentService (vorsichtig!) ist verantwortlich für die Koordination mit externen Zahlungsanbietern.

Warnsignal: Wenn jemand sagt: “Die Klasse macht alles rund um Bestellungen.” → zu groß.

Hohe Kohäsion, niedrige Kopplung

Kohäsion: Dinge, die zusammengehören, sind zusammen.

Kopplung: wie stark Komponenten voneinander abhängen.

Agiles Ziel: Kleine Änderungen, kleine Blastradius.

Coach-Fragen: “Wenn sich die Versandregel ändert – welche Dateien müssen wir anfassen?”
“Können zwei Leute parallel arbeiten, ohne Merge-Konflikte und Seiteneffekte?”

Prinzipien, die Coach wirklich helfen (ohne Dogma)

Single Responsibility (SRP) als Brücke zu slicing

SRP heißt nicht “eine Methode pro Klasse”. Es heißt: Eine Klasse hat einen klaren Grund, sich zu ändern.

In agilen Teams ist das Gold wert, weil es Story-Slicing unterstützt:

Eine Story ändert eine Geschäftsregel → idealerweise betrifft das wenige Klassen.

Symptom bei SRP-Verletzung: Eine Story zieht lange Ketten an Änderungen nach sich.