Problem mit OOP

[struppi]

Ich hab auch nicht gesagt dass OOP etwas schlechtes ist, aber gerade in so einer Umgebung muss man sich genau überlegen was man tut. Und bei einem mittelgroßen Projekt dürfte der Aufwand einen Geschwindigkeitsverlust, nur um einem Entwurfsmuster genüge zu tun , sich nicht lohnen. Es ist ja nicht so, dass die leeren Funktionen unbedingt notwendig wären.

 

[crash]

Naja, wenn man es Objekt-orientiert realisiert, kann man auch einem kleinen oder mittleren Projekt einfacher ein großes machen. Ob der Zeitaufwand höher ist, sei mal dahingestellt.
Ich glaube, dass der Geschwindigkeitsverlust vernachlässigbar gering ist, bei Funktionen die bei der Abstraktion implementiert werden müssen, sofern wir von der Laufzeit ausgehen.

 

[struppi]

Was machen den abstrakte Objekte oder Funktionen einfacher? sie sind einfach nur leer

 

[mermshaus]

(Edit: Sorry, wenn das zu weit ausgeholt ist.)

Abstrakte Klassen sind sinnvoll für Typehinting und können von abgeleiteten Klassen gemeinsam genutzten Code enthalten ("don't repeat yourself").

Scene::add aus meinem Beispiel oben nutzt Typehinting und stellt damit sicher, dass nur Objekte übergeben werden können, die alle in DrawingObject definierten Methoden enthalten (in diesem Fall wird DrawingObject::draw später ausgelöst).

    public function add(DrawingObject $do)
    {
        $this->_drawingObjects[] = $do;
    }

Zudem implementiert DrawingObject Methoden, die für alle zu zeichnenden Objekte zur Verfügung stehen sollen: Hintergrund- und Rahmenfarbe und Position setzen und auslesen.

Diese Aspekte lassen sich auch mit nicht von einer abstrakten Elternklasse ausgehender Vererbung umsetzen. Nur ergibt es inhaltlich keinen Sinn, ein generisches DrawingObject instanzieren zu können, das ohne weitere Konkretisierung nicht sinnvoll als eine Form (etwa ein Kreis) gerendert werden kann. Im Sinne von "Sichtbarkeiten so stark einschränken wie möglich" ist es daher konsequent, die Instanzierung der Klasse völlig zu verbieten.

Denkbar wäre es natürlich, etwa Rectangle von Circle abzuleiten und die draw-Methode entsprechend zu überschreiben. Dann wären beide Klasse normal instanzierbar und es bestünde keine Notwendigkeit für abstrakte Methoden o. ä. und die Quadratur des Kreises wäre geschafft. ;) -- Nein, im Ernst, dieser Weg lässt die Klassenhierarchie willkürlich werden und macht sie schwer zu überblicken.

Die abstrakte Klasse implementiert die Schnittmenge der gemeinsamen Methoden aller von ihr abgeleiteten Klassen und schreibt dazu diejenigen Methodensignaturen vor, die alle abgeleiteten Klassen mindestens implementieren müssen, in denen sich ihre spezifische Funktionalität aber so sehr unterscheidet, dass der Methodencode nicht gemeinsam genutzt werden kann.

 

[struppi]

Mir sind die Aspekte der OOP bekannt.

Aber wenn du die leere Funktion draw aus dem Quellcode beseitigst, funktioniert dein Beispiel genauso (ohne das Schlüsselwort abstrakt).

 

[crash]

Ja, aber für einen zweiten Entwickler wird es so einfacher, nichts zu vergessen.

 

[mermshaus]

Mir sind die Aspekte der OOP bekannt.

Deshalb mein Edit zu Beginn des Posts. Mir wurde erst auf halbem Wege klar, worauf du genau hinauswolltest. ;) Ich dachte, ich lasse die Erläuterungen dennoch stehen, weil es viel Getippe war und weil hier vielleicht außer uns doch noch wer mitliest. (Das Folgende geht jetzt auch nicht speziell an dich.)

Anyhoo:

Im Prinzip dient OOP ja auch dazu, Übersicht zu schaffen und sicherzustellen, dass der Programmierer mit größtmöglicher "Disziplin" arbeitet (ob er will oder nicht), und möglichst wenig Interpretationsraum zuzulassen, welche Funktion wie einzusetzen ist.

Man könnte etwa bei Instanzvariablen darauf verzichten, private und protected zu verwenden. Dann läge es in der Verantwortung des Programmierers, nur die Werte direkt zu verändern, die dafür vorgesehen sind. Eine etwaige Missachtung würde aber im Fall der Fälle einen wahrscheinlich schwierig zu findenden Fehler herbeiführen, während sich beim Einsatz von private und protected sofort der Compiler/Interpreter beschwert, wenn eine Zugriffsverletzung stattfindet.

Das Aufdecken des Fehlers wird "nach vorne" geschoben. So ist das auch bei abstrakten Methoden. Es ist möglich, bereits bei Instanzierung des Objekts zu prüfen, ob eine Methode existiert, statt erst später festzustellen, dass sie wohl nicht existiert, aber hätte existieren sollen.

Wenn sie für dieses Objekt aus irgendeinem Grund nicht aufgerufen wird, kann das unter Umständen erst drei Versionen später zu einem Fehler führen. Wenn das Objekt instanziert werden kann, ist dagegen sichergestellt, dass alle erwarteten Methoden vorhanden sind.

Diese zusätzlichen Hilfestellungen kosten bei der Ausführung natürlich Zeit, reduzieren aber wahrscheinlich in den meisten Fällen den Entwicklungsaufwand (weniger mögliche Fehlerquellen, Code hat "übersichtlichere Struktur", kürzere Einarbeitungszeit in Teamsituationen).

(Ich würde die draw-Methode in der Elternklasse übrigens in diesem Fall mit leerem Methodenkörper implementieren, wenn es keine abstrakten Methoden gäbe. Sonst hätte ich zwei Minuten später vergessen, dass sie existiert.)

Anwendungen werden immer komplexer, Programmiersprachen ermöglichen deshalb immer mehr Abstraktion (ASM -> C -> C++ -> Java ...). Damit will ich aber nicht sagen, dass das unbedingt immer voll ausgeschöpft werden muss. struppi schrieb glaube ich, dass teilweise OOP-Muster einzig aus dem Grund eingesetzt werden, um OOP-Muster einzusetzen. Kein Widerspruch. :)