Strukturiertes vs. objektorientiertes Coden

[Steffen Gerlach]

Hallo,

Ja, ich halte OOP auch für etwas überschätzt. Sie ist eine gute Ergänzung zur proz. Pr., aber kein Ersatz. Wer behauptet, er implementiert jedes Programm rein objektorientiert, der glaubt wahrscheinlich, OO bestünde darin, daß jedes Datum und jede Funktion Member irgendeiner Klasse sind. Wirklich reine OOP kann fürchterlich umständlich sein.

Wie realisiert man z.B. eine Prozedur Doppelpass(Spieler1,Spieler2) in OOP? Vielleicht so: Spieler1.Doppelpass(Spieler2)? Das wäre schon keine richtige OOP mehr, sondern eine Mischung mit prozeduraler Pr. Die wahre OO-Lösung führt eine zusätzliche Klasse ("Doppelspieler"?) ein und schreibt: Doppelspieler(Spieler1,Spieler2).Doppelpass...

Anderes Bsp: RoteKarte(Team,Spieler), sieht in OOP so aus: Team.Spieler.RoteKarte - toll, nur leider ist so innerhalb von RoteKarte zwar der Spieler (implizit, this) bekannt, nicht aber das Team (beforethis?). Man müßte es entweder als prozeduralen Parameter übergeben (keine OOP, hehe!) oder aber in der Spieler-Klasse ein zusätzliches Datenfeld einrichten, das man irgendwann vor Aufruf von RoteKarte für jeden einzelnen Spieler mit einer Referenz auf das Team initialisiert.

Meine Meinung: OOP macht sich dann gut, wenn (1) es sich anbietet oder (2) wenn mehrere Personen an einem Projekt arbeiten und eine klare, nachvollziehbare Schnittstelle benötigt wird. OOP auf Krampf bringt's nicht.

Gruß
Steffen