OOP (Object Oriented Programming)

Die 4 Säulen der OOP:

1. Kapselung (Encapsulation): Verstecke das Innere. Niemand darf motor.schraube direkt anfassen. Nutze auto.fahreLos(). (Private vs. Public).
2. Vererbung (Inheritance): "Sportwagen" erbt von "Auto". Er kann alles, was Auto kann (+ Turbo). Spart Code-Duplizierung.
3. Polymorphie (Polymorphism): "Hund" und "Katze" erben von "Tier". Beide haben machGeräusch(). Wenn ich tier.machGeräusch() rufe, bellt der Hund und miaut die Katze. Der Code muss nicht wissen, was genau es ist.
4. Abstraktion: Zeige nur das Wichtige. Ein Lenkrad ist einfach zu bedienen, egal wie komplex der Motor ist.

1. Composition over Inheritance

Anfänger lieben Vererbung. ("Banane erbt von Obst erbt von Pflanze erbt von Ding...") Problem: Gorilla-Banane-Problem. Du willst die Banane, kriegst aber den Gorilla, der sie hält, und den ganzen Dschungel dazu. Vererbung ist starr. Profi-Tipp: Komposition. Statt "Mensch IST EIN Säugetier" sagst du "Mensch HAT EINE Lunge". Du steckst Lego-Bausteine zusammen (Modules/Traits), statt riesige Stammbäume zu bauen.

2. SOLID Prinzipien

Die Bibel für gutes OOP.

• Single Responsibility: Eine Klasse macht genau EIN Ding.
• Open/Closed: Offen für Erweiterung, geschlossen für Änderung.
• Liskov Substitution: Ein Sportwagen muss sich überall verhalten wie ein Auto (darf nicht crashen, wenn man langsam fährt).
• Interface Segregation: Lieber viele kleine Interfaces als ein riesiges.
• Dependency Inversion: Verlasse dich auf Abstraktionen, nicht auf Details.

3. Anemic Domain Model (Anti-Pattern)

Du hast Klassen User, Order – aber die sind leer (nur Daten). Die Logik liegt in UserService, OrderManager. Das ist eigentlich prozedurale Programmierung im OOP-Kostüm. Echtes OOP ("Rich Domain Model"): Die Klasse Order hat eine Methode calculateTotal(). Die Daten bringen ihre Logik mit.

1. VTables und Dynamic Dispatch

Wie weiß der Computer in C++, dass bei tier->machGeräusch() bei einem Hund ein Bellen und bei einer Katze ein Miauen ausgeführt werden muss, wenn die Variable zur Compilezeit nur als Tier typisiert ist? Das Geheimnis ist die VTable (Virtual Method Table). Jede Klasse mit polymorphen (virtuellen) Methoden erhält unsichtbar ein Array von Funktions-Pointern. Wird ein Hund-Objekt instanziiert, trägt der Compiler in dessen VTable die Adresse der Hund-Bellen-Funktion ein. Der Aufruf tier->machGeräusch() ist also keine feste Sprungadresse zur CPU, sondern eine indirekte Zeigerauflösung zur Laufzeit (Dynamic Dispatch). Das kostet minimal CPU-Overhead, ermöglicht aber abstrakte Architektur.

2. Das Diamond Problem (Multiple Inheritance)

Sprachen wie C++ erlauben Mehrfachvererbung. Klasse D erbt von B und von C. B und C erben vorher beide von A (Formt einen Diamanten). Die Katastrophe: Klasse A hat die Variable x. D hat nun plötzlich zwei physische Kopien von x im Arbeitsspeicher (einmal über B vererbt, einmal über C geerbt). Der Compile wirft einen Mehrdeutigkeits-Error. Dieses "Diamond Problem" ist der Grund, warum Java, C# oder TypeScript strikt Multiple Inheritance bannen und nur "Multiple Interfaces" erlauben (Interfaces besitzen keinen impliziten State, daher keine Kopier-Züge).

3. The OOP vs. Data-Oriented Design (DOD) Clash

Die Gaming-Industrie meidet OOP heute zunehmend. Warum? CPU-Caching. In OOP definierst du: class Player { int hp; Vector3 pos; } und baust ein Array aus 10.000 Playern. Der RAM speichert Player1(hp, pos), dann Player2(hp, pos). Die Grafikkarte will nur alle Positionen iterieren, muss aber gezwungenermaßen immer über die nutzlosen hp Speicherblöcke drüberspringen. Das vernichtet Caching-Lines im L1 CPU-Cache (Cache Misses). DOD (Entity Component Systems, z.B. in Unity) trennt Daten radikal von Behavior. Es speichert Array_All_HP und Array_All_Pos in dicht gepackten RAM-Lines, was Schleifen-Berechnungen durch Data-Locality plötzlich um den Faktor 100 beschleunigt.