OOP Missverständnisse: Wiederverwendbarkeit

[bokel]

Wiederverwendbarkeit wird immer wieder als ein wichtiges, wenn nicht sogar das wichtigste Ziel bei OOP angeführt. Quasi magisch soll sich die Programmierung eines Projekts auch beim nächsten Projekt benutzen lassen, möglicherweise leicht verändert durch Vererbung. Nach meiner Erfahrung ist das Quatsch! Und gefährlicher Quatsch dazu. Denn der Gedanke an Wiederverwendbarkeit führt dazu, daß man wesentlich komplizierter vorgeht, als es für die aktuelle Aufgabe wirklich nötig ist.

Wiederverwendbarkeit tritt eher zufällig ein. Entweder bei grundlegenden Funktionen in Form einer Bibliothek z.B. von Stringfunktionen oder weil man eine spezielle Art von Projekt mehr als einmal macht. Dann ergibt sich möglicherweise sowas wie ein Framework für diese Art von Projekt.

Das wahre und wichtigste Ziel von OOP ist Lokalität. Lokalität bedeutet, dass eine Klasse möglichst wenig Voraussetzungen an ihre Umgebung stellt. Globale Referenzen z.B. oder in Flash die Referenz auf root - das sind solche Kameraden, die die Lokalität einschränken.

Die Frage ist, was hat man von Lokalität? Am wichtigsten wäre da zu nennen, dass durch Lokalität auch Änderungen lokal bleiben und nicht zu Folgeänderungen an ganz anderen Stellen führen. Ein anderer Vorteil ist das leichtere Verständnis. Wenn lokal alle Voraussetzungen bekannt sind, reicht es, den lokalen Code zu lesen. Man muss nicht erst die ganzen Voraussetzungen verstehen. Und ganz zum Schluss landen wir auch wieder an unserem Ausgangspunkt. Lokalität führt letzlich auch dazu, dass sich eine Klasse leichter wiederverwenden lässt, fehlende Lokalität dagegen macht es u.U. sehr schwer eine Klasse wiederzuverwenden. Wiederverwendbarkeit ist also Folge der sauberen OOP und nicht das Ziel.

mfg. r

[André Michelle]

Auch Naturwissenschaftler versuchen Modelle zu finden, die Probleme in möglichst vielen Situationen beschreiben können. Aber der Wissenschaftler sucht auch nicht nach einem Model aufgrund der Wiederverwendbarkeit, sondern nach Sicherheit in der Voraussage. Daher muss er auch in seiner Beweisführung möglichst viel Abschirmung nach aussen erreichen.

Umso feingliedriger das Model, desto mehr komplexe Dinge lassen sich voraussagen. Das Denken ist in der Programierung ähnlich. Letztendlich ist deine Ausführung aber auch nur ein Jonglieren mit Begrifflichkeiten, um nicht zu sagen philosophisch. Mich reizt zwar an der Programmierung die Vorstellung, dass man durch die Wahl (Besser Entdecken) der geeigneten Modelle jedes noch so komplexe Problem in den Griff bekommen kann, aber manchmal ist Newton der Quantenmechanik vorzuziehen, weil die Arbeitszeit der Implementation in keinem Verhältnis zum erzielten Ergebnis steht.

Die Frage ist, was hat man von Lokalität? Und da kommen wir wieder zurück zu unserem Ausgangspunkt. Lokalität führt dazu, dass sich eine Klasse leichter wiederverwenden lässt, fehlende Lokalität dagegen macht es u.U. sehr schwer eine Klasse wiederzuverwenden.

Das finde ich etwas mau. Also Lokalität, um Wiederverwendbarkeit zu erreichen ist zuvor nicht als Ziel deklariert worden.

Wichtiger ist doch, dass Lokalität ein Projekt erst nachvollziehbar macht. Auch während der Entwicklung ist eine eindeutige Unterteilung und somit Reduzierung der Probleme nützlich. Die Wiederverwendbarkeit ist tatsächlich völlig egal. Nett, wenn möglich, schnell gemacht wenn nötig.

[bokel]

Ja, da hast du Recht. Ich habe die ganzen anderen Vorteile von Lokalität der schönen Konstruktion des Artikels geopfert. Lokalität hat natürlich wesentlich wichtigere Vorteile als Wiederverwendbarkeit. Aber die verdienen eigentlich einen eigenen Thread.

Edit: danke für den Hinweis, ich habe den Text oben angepasst

mfg. r

[elias]

Der Punkt ist wohl nicht neu. Wikipedia hat was interessantes dazu:

Reusability is the benefit most often claimed for OOP. However, that is unlikely to be true, as reuse of software is as old as the invention of the subroutine, reputedly prior to 1950. In fact, reuse is frequently disputed as being a primary, or even a large, benefit. The ease of translation to and from the target environment, the (improved) ability to maintain a program once written, the ability to do localized debugging, and the (improved) ability to do much larger parallel development efforts are all cited as more significant reasons to use an OOP language.
http://en.wikipedia.org/wiki/Object-...ed_programming

Unter wiederverwendbarkeit verstehe ich nicht das ich jedes Objekt
das ich schreibe irgendwann wieder einsetzen kann/muss. Das wird erst
mit Aufgaben möglich die sich man sauber in eine Komponente verstecken
lassen. Trotzdem halte ich es für sinnvoll die einfachen Mittel die deine
Objekte Wiederverwendbarer machen einzusetzen. Auf PHP Bezogen wären
das zb echo's im Code oder hardgecodete Pfade. Banal aber bringt einiges.
IoC halte ich auch
für einen entscheidenden Schritt richtung Wiederverwendbarkeit.
Allerdings sehe ich diese Mittel nicht umbedingt im Sinne deiner 'Lokalität',
tatsächlich würde ich an vielen stellen vor dem 'new' Operator schreiend
weglaufen.

[edit]
Was ich hier im AS Bereich bezogen auf MVC auch oft vermisse ist die
erwähnung eines Service Layers. Der Ansatz ist
noch sehr frisch für mich. Ich bin gezielt darauf gestossen als mir Aufgefallen
ist das ich in verschiedenen Controllern sehr oft ähnliche Routinen habe.
Das könnte ich mit einem SL reduzieren und hätte besser wiederverwendbare
"Services".

Naja für mich läuft es darauf hinaus das "Wiederverwendbarkeit" einfach
zu allgemein ist. Es geht auch um interne Wiederverwendbarkeit.

[atothek]

Sehr schöne Thema.

Für mich gibt es eben die Trennung von Framework und Projekten.
Das Framework ist eine permanent wachsende API,
ein Projekt hingegen ist in sich geschlossen(Lokalität). Wenn ich bei der
erstellung eines Projektes auf eine Problemstellung komme die Projektübergreifend
von interesse ist, werde ich sie vermutlich ins Framework mit aufnehmen,
wenn nicht ist es eine reine Projektabhängige Umsetzung,
die Wiederverwendbarkeit ist dann fast null.

Wenn ich ein neues Projekt anfange können zum teil Parts aus anderen Projekten
dafür von interesse sein, wenn ich glaube das es sinnvoll ist refaktorisiere ich das entsprechende Projekt
und laß die neuen Projektübergreifenden Objecte ins Framework fließen.

Letztlich ist es sich ständig veränderndes Konstrukt, ich finde es auch gut.
Sehr passend finde ich die Aussage über zu komplex geratenden Wollmilchsäue
um 1001 Möglichkeiten abzudeken, das ist wie Ralf sagt,
wirklich Gefährlich und auch sehr schlecht zu pflegen, erweitern etc.
Martin Fowler hat da mal zu gesagt das Klassen noch keine OOP ausmachen, es gebe viele Prozedurale projekte die OOP strukturen nutzen, spontan fällt mir da PEAR ein das sicherlich seine berechtigung hat aber nicht wirklich Objektorientiert ist.

MfG
Alex

[Janoscharlipp]

Seltsam, ich finde gerade das Programmieren hinsichtlich der Wiederverwendbarkeit gut. Es führt in meinen Augen oft zu besseren Lösungen, die nicht einfach hingepfuscht werden, sondern in die auch ein wenig Hirnschmalz gesteckt wird.
Natürlich kann man das auch übertreiben, man muss eben immer abwägen, wie sinnvoll eine Verallgemeinerung ist, und wieviel Zusatzaufwand es ist.

Auf die Bibliothek, welche sich hier angesammelt hat, wollte ich jedenfalls nicht verzichten

[hgseib]

z.b. KI. ich kann auch mit basic saubere ordentliche KI-programme schreiben. nur in z.b. lisp geht es einfacher, weil das speziell dafür entwickelt wurde.
ich kann auch 'normale' funktionen sauber erstellen (das sie keine variablen von ausserhalb benützen usw.), gliedern und wiederverwenden. nur OO erreiche ich das gleiche einfacher, weil das speziell dafür entwickelt wurde.

die verwertbarkeit eines codes hängt also nicht nur von der methode ab, sondern auch sehr stark vom programmierer selbst! 'schlechtes' OO-tes zeugs (doku wie funktionalität) von einem anderen programmierer zu benützen macht mehr arbeit, als gut dokumentierte einfache funktionen.

aber wem erzähle ich das? ;-)

vermutlich erstellt du projekte, die sich kaum ähneln? da ist's natürlich auch schwer ähnlichkeiten zu finden. firmen erstellen i.d.R. immer das gleiche - kundenangepasst. da machts wohl grossen sinn.

[r0b]

Ich würde sagen das Wiederverwendbarkeit und Lokalität (saublödes Wort), sagen wir besser die Unabhängigkeit eines Konstrukts von anderen Teilen des Codes Hand in Hand gehen.
Bei Klassen oder Methoden die für sich autark sind ergibt sich dann als Resultat zwangsläufig eine Wiederverwendbarkeit, eben weil diese Lösung unabhängig oder linear arbeitet. Ein (oder mehrere) Parameter gehen rein, ein Ergebnis kommt zurück, ohne weitere Abhängigkeit.

Worum es meiner Meinung nach eigentlich geht ist Zeitersparnis, oder Übersichtlichkeit. Was dann wieder zu Zeitersparnis, und das dann wieder zu mehr Kohle oder mehr Freizeit führt.

Was war denn eigentlich der Hintergedanke diesen Post zu starten bokel?

[André Michelle]

Zitat von WIKIPEDIA

Abstraktion bezeichnet einen Prozess, der auf individuelle, zufällige Einzelheiten zugunsten des Allgemeinen, Wesentlichen verzichtet. Es wird dabei eine Einheit gebildet, die sich vom Objekt distanziert.

Daran erkennt man, dass schon der Ausdruck OOP (Objektorientiertes Programmieren) falsch interpretiert werden muss, weil man sich letztendlich eben nicht am Objekt orientiert, sondern an Verhältnissen, Beziehungen. OOP ist zwar technisch der Umgang mit Objekten, aber diese sollten möglichst abstrakt formuliert sein. Daraus 'kann' eine Wiederverwendbarkeitkeit entstehen, es muss aber nicht zwangsläufig darauf hingearbeitet werden.

Seltsam, ich finde gerade das Programmieren hinsichtlich der Wiederverwendbarkeit gut.

Ich habe noch nie etwas 100%-ig wiederverwendet. Meistens kopiere ich die relevanten Stellen einer Problemlösung (mit Verbesserungen aufgrund weiterer Erfahrungen) in den neuen Kontext. Aber Bokels Abriss hat mir wieder einen neuen Blickwinkel gegeben. Tatsächlich hatte ich bisher auch immer mit der Wiederverwendbarkeit argumentiert, aber das ist Käse. Eine Konzentration auf die wichtigeren Dinge wie Nachvollziehbarkeit ist schlauer, als sich mit Recycling aufzuhalten. Recycling bringt Dich als Ziel kein Schritt weiter, da der 'Rohstoff' sich ständig verändert.

Es ist eine feine Neubewertung der Lage, aber sie gefällt mir sehr gut.

[bokel]

@r0b
Der Grund für das Posting ist, dass ich in Anfängernfragen immer wieder was von Wiederverwendbarkeit lese. Wiederverwendbarkeit ist ein so hohes Ideal, dass kann einem richtig Angst machen, insbesondere einem OOP Einsteiger. Hier ist mal ein Beispiel. Dem wollte ich ein wenig vorbeugen.

Ganz allgemein habe ich natürlich nichts gegen Wiederverwendbarkeit. Bei jedem sammeln sich ja wohl im Laufe der Zeit Schnipsel, Klassen, Techniken usw. an, die man wieder verwendet. Aber das braucht eben seine Zeit und ist nicht das ursprüngliche Ziel.

Was du über Zeitersparnis sagst, sehe ich genauso. Letztlich soll uns Programmierung das Leben einfacher machen und nicht komplizierter. Noch so ein Punkt, den ich auch immer mehr berücksichtige. Wenn ich die Wahl habe zwischen einer Implementation, die vielleicht etwas mehr Performance bietet und einer, die bequem und nach aussen hin einfach ist, wähle ich immer öfter die bequeme Variante. Bibliotheken sollten mir Arbeit abnehmen und nicht welche aufhalsen.



mfg. r

[r0b]

Es war mich doch so als wenn ich mich hier irgendwie angesprochen gefühlt habe.

Wobei dort im 2ten Satz:

Es kommt natürlich darauf an wie du zur Zeit arbeitest und wie du normalerweise deine Programmierung organisierst. Eigentlich "muß" man überhauptnix. Man muß nur irgendwann mit der Arbeit fertig werden, und natürlich später bei der ersten Änderung noch durch den Code durchsteigen können.

Das ist meine praxisbezogene Sicht von OOP. Wenn wir das Konzept weiterspinnen landen wir irgendwann bei eventbasierter Organisation, Proxies, Factories und MVC. Also eine weitere Abstraktion des Ganzen mit dem Ziel größere Übersicht, bessere Verständlichkeit und leichtere Wiederverwendbarkeit zu erreichen.

Wobei ich bei Wiederverwendung jetzt natürlich keine 1zu1 Geschichte meine. Aber eine gute Model View Controller Struktur oder eine dynamische Navigation, die man schon in 2-3 Projekten genutzt hat ist dann soweit gereift, das man sie immer wieder - jeweils mit Änderungen, Ergänzungen oder Teilverbesserungen wieder nutzt.

Und das spart im Endeffekt Zeit. Alles andere ist Spielkram. Designer machens schick und Programmierer habens dann zum Laufen zu bringen. Wie ist Latte. Hauptsache es funktioniert und es ist am besten gestern schon fertig, um es jetzt mal etwas drastisch zu sagen.

Gruß

Robert

Edit: Beim nochmaligen lesen der posts oben drüber fällt mir auf das ich irgendwie an der Sache vorbeirede... Ich glaube ich arbeite zu viel.

[atothek]

Bibliotheken sollten mir Arbeit abnehmen und nicht welche aufhalsen.

Wie oft und welche Libs verwendet Ihr denn regelmäßig bei Projekten?
Und wieviel coded Ihr nach/neu das es schon wo anders gibt aber nicht ganz genau euren vorstellungen entspricht?

MfG
Alex

[bokel]

Gute Frage atothek,

regelmäßig setze ich eigentlich nur meine eigenen Sachen und die ASUnit ein. Neulich habe ich mal das AP benutzt, aber nur sehr oberflächlich.

mfg. r

[Janoscharlipp]

Habe grade eine riesen Aktion von Abhängigkeitseliminierung hinter mir ... alle Quellen mit unklaren Lizenzen mussten raus, in Folge dessen gab es einiges zu ersetzten, beispielsweise alles was mit Zeichnen zu tun hat.
Habe mir deshalb mal das AnimationPackage angesehen, war dann aber ziemlich enttäuscht, habe einen Tag investiert, und alles selber gemacht.
Was mich auch immer schockt ist, wenn ich nur wegen einigen Funktionen plötzlich die halbe Bibliothek mit im Boot habe.

Zitat von André Michelle

Recycling bringt Dich als Ziel kein Schritt weiter, da der 'Rohstoff' sich ständig verändert.

Das kommt ganz darauf an, was du mit Flash machst. Hier beispielsweise werden Anwendungen gebastelt, die sich im Aufbau ziemlich ähneln (-> basieren alle auf dem gleichen Framework) zum anderen aber auch verwandte Funktionalität bieten. Und bei letzterem lernt man Wiederverwendbarkeit sehr zu schätzen, dank ihr kommt man immer schneller immer weiter.

Allerdings hat Wiederverwendbarkeit auch ihre Grenzen, schon mehrmals habe ich Sachen wiederverwendbar gemacht (d.h. verallgemeinert, ausgelagert ...) wodurch sie so abstrakt und kompliziert wurden, dass sie nie wieder jemand anfassen wird, weil sie augenscheinlich zu weit vom Problem weg sind. (selbst wenn sie dieses im Einsatz extrem vereinfachen könnten)

Edit:
In der Zwischenzeit zeigt sich sogar, dass das Framework auch für vollkommen andere Anwendungen eingesetzt werden kann, zwar werden so mache Teile überhaupt nicht verwendet, andere werden ergänzt, aber allein dass der Aufbau der gleiche ist, ist extrem Hilfreich für andere sich einzuarbeiten.

[elias]

Also minimum ist meine Template Klasse wenn es um Text oder HTML geht.
Für Datenbankzugriffe hab ich bis Dato im PEAR::DB genutzt, aber gut möglich
das diese Gewohnheit bald PDO platz machen muss.
Als ORM Layer benutze ich momentan Propel, würde ich auch wieder benutzen
wenn die Aufgaben nich zu speziell sind.
Für Mail PHPMailer. Zum testen PHPUnit2, obwohl ich schon länger mit SimpleTest
liebäugel.