Kategorien
OOP unter PHP?
Die objektorientierte Programmierung hat ihren festen Platz in der Programmierung gefunden, zu groß scheinen die Vorteile um darauf zu verzichten. In PHP hingegen wird noch viel prozedural programmiert und über den Sinn oder Unsinn der Objektorientierung gestritten. Haben Sie vielleicht Kollegen, die den Segen der OOP noch nicht verinnerlicht haben? Oder sind Sie vielleicht selbst noch gar nicht von der OOP überzeugt?
Versprechen der OOP
Die Kapselung von Daten, Steuerung der Sichtbarkeit und der Schutz von Methoden und Attributen. Vererbung bis hin zu Mehrfachvererbung, Überladung, Polymorphismus und endlich, endlich auch Persistenz im Gegensatz zu dem kurzen Aufflackern der Daten in einer Funktion. Nicht zu vergessen die Behandlung von Exceptions.
Auch wenn PHP nicht alles davon in Vollendung bietet, ist PHP seit Version 5 eine Sprache mit der sehr gut objektorientiert entwickelt werden kann.
Wer in Teams oder an großen Projekten arbeitet kann getrennt von anderen entwickeln, nur Schnittstellen müssen bekannt gemacht werden. Wie Klassen intern funktionieren, spielt keine Rolle mehr. Die Wartung von Code wird erleichtert, interne Änderungen haben keine Auswirkungen nach außen. Klassen können wiederverwendet werden, in Folge-Projekten kann die Entwicklungszeit reduziert werden.
Die Realität kann als Vorbild in Klassen und Objekten abgebildet werden – nicht nur bei der Programmierung, sondern bereits bei der Analyse und beim Design.
OOP? Nein danke!
Wer von der OOP überzeugt ist, braucht naturgemäß nicht mehr überzeugt werden – für alle anderen muten die üblichen Argumente für OOP eher kryptisch und abschreckend an.
Vor allem die berüchtigste aller Aussagen “Alles ist ein Objekt”, hat etwas von der stereotypen, aber unverständlichen Frage “Sind Sie außer Gefahr” aus dem Film “Der Marathon Mann” als Dustin Hoffman auf einem Zahnarztstuhl gefoltert wird.
Wie sieht die Entwicklung mit PHP (oft genug) aus?
Wenig Zeit, vage und sich ändernde Anforderungen. Einmann-Entwicklung von der Analyse bis zur Umsetzung. Kurzfristig und nur als Zwischenlösung gebraucht – dann aber jahrelang im Einsatz sind, “weil es ja so gut läuft”.
PHP ist der Notnagel, mit dem “mal eben” Anforderungen umgesetzt werden sollen, die mit anderen Systemen erst gar nicht angegangen werden – sei es, dass zu wenig Ressourcen vorhanden sind oder das ganze eben nichts kosten darf, aber eben doch zu wichtig ist um es nicht zu machen. Und “bekannterweise” kann man das mit PHP “doch mal schnell” umsetzen – “das kann doch nicht lange dauern”.
Wer alleine arbeitet, braucht seine Funktionen und Variablen nicht zu kapseln. Ein unerlaubter Zugriff auf den eigenen Code durch andere stellt kein Problem dar wenn jeder Entwickler seine eigenen Seiten oder ganze Bereich entwickelt. Die Absprache mit den Kollegen beschränkt sich auf Datenbankwerte oder Parameterübergaben zwischen Seiten. Ein Konflikt auf Code-Ebene ist ausgeschlossen.
Webseiten ergeben ein großes Ganzes, die Seiten bleiben aber oft unabhängige Einheiten, anders als bei einer klassischen Applikation in der die Arbeiten aller Beteiligten in einem großen Programm zusammenfließen.
Die Realität abbilden? Wer sagt, dass die Realität für einen Prozess ideal ist? Wie sollen zahlreiche von der Realität hergeleitete Objekte “Kundenbetreuer”, “Kunde”, “Bestellung” von Seite zu Seite weitergegeben werden? Serialisierung macht nicht wirklich viel Spaß.
Wartbarkeit oder Wiederverwendung von Code? Auch Funktionen und includes lassen sich wiederverwenden. Persistenz? Wozu wenn sich alles sowieso auf einer Ebene befindet und damit dauerhaft im Zugriff ist?
Nicht jeder programmiert als Wochenendaufgabe ein zweites Facebook oder ein komplexes CMS. PHP ist nicht umsonst eine Multiparadigmen-Programmiersprache.
Es lebe die OOP!
Objektorientierte Programmierung bietet auch und gerade unter PHP viele Vorteile, nur sind die gebetsmühlenartig wiederholten Argumente unpassend und schrecken gerade die ab, die sie erreichen wollen.
OOP bietet eine einfache Möglichkeit Code effizient in kleine und kleinste Module zu unterteilen. Komplexe Strukturen lassen sich aufbrechen und entscheidend vereinfachen. Bereits kurzer Programmcode kann sinnvoll unterteilt werden und damit die Lesbarkeit (auch und insbesondere) des eigenen Codes verbessert werden.
Funktionen sind beschränkt, nur ein Parameter kann zurückgegeben werden – auf Objekte kann immer wieder zugegriffen werden und sie können viele Parameter zur Verfügung stellen. Klassen sind eigentlich so etwas wie “Mega-Funktionen” – nur hätte diesen Namen erst recht niemand gekauft.
Das Testen von Code der so modularisiert ist, eindeutige Schnittstellen hat und für sich steht, ist wesentlich einfacher.
Die Festlegung der Sichtbarkeit von Methoden und Attributen mit public, private oder protected dient nicht nur dem Schutz, sondern ist auch Dokumentation bei dem Monate später erfolgenden Blick auf den dann schon wieder verstaubten und vergessenen Code (vergleiche “PHP objektorientiert” von Peter Lavin).
Die Aufteilung einer Aufgabe in Klassen, Methoden und in Attribute dient nicht nur einer abstrakten Modularisierung, sondern macht den Code lesbarer und ist eine dokumentierte Lösung des Problems.
Eine langsamere Ausführungsgeschwindigkeit? Vergessen Sie es, der vielbeschworene Overhead ist gering und Optimierungsmöglichkeiten gibt es an anderen Stellen genug.
Fazit
Es lebe die OOP in PHP, nur die Hochglanzbroschüre für die Anpreisung sollte überarbeitet werden. Oder wie halten Sie es mit der OOP?
in php und der entwicklung fuer das web halte ich oop fuer nicht notwendig. zu aufwendig. zu viel balast.
interessanter ist es bei umfrangreichen programmsystemen mit vb oder csharp.
fuer webseiten reicht das wissen bestehende klassen zu benutzen.
interessanter wird da schon funktionale programmierung. aber da hapert es gewaltig in php
Programmieren habe ich gelernt mit C++ und kam erst später durch private Projekte zu PHP. In C++ Programmen ist OOP ein Standard. Wer darauf verzichtet, hat einfach das Konzept und die Vorteile von OOP nicht verstanden, so meine Meinung. Oft liegt es einfach daran, dass man noch nie ein großes Projekt realisiert hat, so dass man denkt mit ein paar Funktionen ist alles erledigt.
So habe ich auch gedacht als ich mit PHP angefangen habe. Jede Seite für sich, paar Funktionen für Datenbank abfragen und dann geht es schon. Das ging so lange gut, bis ich ein größeres Projekt angegangen habe. Nicht irgendeine einzelne Webpage, sondern eine komplette Website mit vielen Datenbank abfragen, Daten-Darstellungen, Editierungsmöglichkeiten und Validierungsabfragen. Und da fing es an, dass der Code redundant wurde, die Übergabe von Daten war einfach schrecklich anfällig auf Änderungen und und und.
Erst da habe ich mir viele Tutorials zu OOP in PHP durchgelesen (wobei es keine wirklich tiefgehende gibt) und mir ein Buch über Designpattern in PHP besorgt. Nach dem ich einige Tage damit verbracht habe die wichtigsten Sachen abkapseln, hat das Programmieren wieder richtig Spaß gemacht. Wo früher für eine Datendarstellung 100 Zeilen Code standen, waren auf ein Mal nur 10 und dann noch so, dass sie auch ohne Kommentare selbsterklärend waren. Das Projekt wurde wieder überschaubar, obwohl an der Größe des Codes sich nicht viel verändert hat, es war einfach alles viel besser organisiert.
Also meiner Meinung nach sollte ein PHP Programmierer sehr wohl auf OOP setzen. Es muss nicht so extrem wie in Java sein, wo jeder Scheiß eine Klasse ist, aber der Verzicht auf die Kapselung und Vererbung ist ein großer Nachteil, auch wenn man alleine arbeitet.
Auf OOP in PHP möchte ich auch nicht mehr verzichten.
OOP macht die ganze Projektarbeit wesentlich einfacher.
Ich bin während eines Projektes von prozeduraler auf objektorientierer Programmierung umgestiegen. Nicht nur das der Quellcode wesentlich schlanker und übersichtlicher wurde, das Skript lies sich auch wesentlich besser debuggen (meiner Meinung nach).
Wenn man es erst einmal verstanden hat, weiß man meist gar nicht mehr wieso man prozedural programmiert hat 😉
Ich gehöre auch zu der Sorte „Einzelkämpfer“ bei Webprojekten in PHP. Da ich nicht in meiner Entwicklung stehen bleiben möchte, habe ich angefangen mit OOP in PHP zu arbeiten. Im Endeffekt bin ich mit der Benutzung von CakePHP dazu gekommen.
Trotzdem fällt mir das OOP schwer und ich erwische mich, wie ich oft in prozedurale Programmierung zurückfalle.
Leider arbeite ich nicht in einem Team, bei der OOP Pflicht ist. stattdessen versuche ich mich selber weiterzubilden, aber ich finde einfach keine geeigneten Tutorials oder Schulungen, die mir mal ein Gesamtkonzept an einem praktischen Beispiel von Anfang bis Ende vermitteln 🙁
Die Tutorials die ich kenne, behandeln zwar die Syntax von OOP, doch wird jeder Befehl nur für sich besprochen. Schlimmer noch sind die Tutorials, mit dem nervigen Vergleich, dass „Autos auch nur Objekte sind“ und man dann dort Instanzen von blauen und roten Autos ablegen kann. Was hat das mit Webseiten zu tun?
Wer weiss also Rat, wie ich trotzdem an mein Ziel OOP komme? Kennt ihr gute Bücher oder Tutorials, evtl. Schulungen? Ich wäre euch sehr dankbar.
„Wenig Zeit, vage und sich ändernde Anforderungen. Einmann-Entwicklung von der Analyse bis zur Umsetzung. Kurzfristig und nur als Zwischenlösung gebraucht – dann aber jahrelang im Einsatz sind, “weil es ja so gut läuft”.“
Ich frage mich, lieber Autor, was PHP diesbzgl. so besonders auszeichnet? Ich kenne das aus JEDER mir bekannten Programmierwelt. Ob Java, .NET, Rails, ja sogar Delphi und Co – überall der gleiche Spaß 🙂 Aber irgendwie wäre unser Job ja auch langweilig, wenn immer alles perfekt liefe :o)
Ich denke es kommt vor allem auch darauf an, ab wann man etwas als OO ansieht.
Ich finde nämlich das man noch lange nicht OO programmiert, nur weil man alles in Klassen packt.
@Maxim: Aber gerade das in Java alles als Objekt repräsentiert ist, ist eben strikte OOP.
In PHP ist es doch oft so, dass jemand ne Klasse mit 10 statischen Methoden zur Validierung schreibt und dann sagt, er würde OO programmieren und das ist einfach nicht war.
Objektorientiert wird es erst wirklich, wenn eine Interaktion zwischen den Objekten stattfindet und auch erst, wenn dadurch ein Mehrwert entsteht (z.B. Schnittstellen verbessern, etc.), imho.
Da hier prinzipiell OOP mit prozeduraler Programmierung verglichen wird, frage ich mich, wie gut ihr prozedural programmieren konntet und wie es um eure OOP-Kenntnisse steht. Ist euer OOP-Code deshalb besser, weil ihr euch mehr mit dem Paradigma vertraut gemacht habt als mit prozeduraler Programmierung? Ich kann mich an kein einziges Tutorial bzgl. prozeduraler Programmierung erinnern, wo „Best Practices“ erläutert wurden – ganz im Gegensatz zur OOP.
Weiterhin stellt sich die Frage, inwiefern andere Konzepte in die Effizienz eines Paradigmas einfließen. Prozedurale Programmierung ohne ein geeignetes Modularisierungskonzept erscheint mir beispielsweise nicht sinnvoll, bei OOP hingegen wird Modularisierung von Haus aus mitgeliefert.
Im Endeffekt steht der Programmierer (mit seinen Erfahrungen) im Vordergrund. Wenn er sein Werkzeug und das zu lösende Problem verstanden hat, dann kann er eine gute Lösung erarbeiten.
Ich persönlich ziehe OOP der prozeduralen Programmierung vor, weil ich in OOP mehr Erfahrung besitze. Allerdings programmiere ich mittlerweile lieber funktional. 🙂
Mir erschließt sich leider nicht ganz, was uns der Autor damit sagen möchten. Es scheint mir ein Artikel ohne Aussage. Er regt nicht an zu denken oder sich weiter zu informieren. Schade.
Wenn es ein Artikel sein soll, der OOP unter PHP zeigen soll, wieso nutzt man dann keine Beispiele? Solche Artikel gibt es ja wie Sand am Meer. Der Autor selber schreibt ja auch, „für alle anderen muten die üblichen Argumente für OOP eher kryptisch und abschreckend an“ – da wird dieser Artikel leider keine Ausnahme sein. Nochmal: Schade.
Das ist wirklich nicht böse gemeint, sondern als konstruktive Kritik zu verstehen: Ich hätte mir Artikel gespart.
at kim
bei projekten mit csharp sehe ich das nicht so. damit wird nicht mal eben umgesetzt. auch bei java kenne ich das von kollegen anders. natuerlich gibt es zeitdruck 🙂
aber mit allem was scriptsprachen sind da wird die zeit schon immer gleich kuerzer veranschlagt. dokumentationen oder pflichtenheft spart man sich da auch gerne und laesst den programmierer einfach machen und dafuer oft auf wunsch aendern.
Ich mag den Artikel. Er widerspiegelt den „inneren“ Kampf zwischen objektorientierter und prozeduraler Programmierung.
Generell gilt, dass noch so strikte OOP (wie z.B. in Java) nicht vor schlechtem oder schlecht-strukturiertem Code schützt.
OOP != Clean Code.
Man kann auch in Java alles in statische Methoden einer Klasse knallen oder prozedural alles in der main Methode programmieren.
Es fällt aber schwerer und genau das ist der Punkt:
Von OOP wird man in die richtige Richtung geschoben, nämlich modularen Code zu schreiben. Es werden die nötigen Konzepte und Werkzeuge geliefert.
Bei prozed. Prog. müsste man eben Konzepte und Konventionen entwickeln um modular zu entwickeln.
Ich bezweifle nicht, das es „schöneren“ prozeduralen als objektorientierten Code geben kann, aber gesehen hab ich das noch nicht.
Dass es zu wenige oder schlechte Tutorials für OOP gibt ist tragisch.
Dass Programmierer ohne OOP Kenntnisse deshalb prozed. programmieren ist verständlich.
Bei mir lief es ähnlich wie bei Maxim: Von Java über prozed. PHP hin zu objektorientiertem PHP… und ich liebe OOP! 🙂
MiAsin,
das hat _nichts_ mit der Sprache zu tun. Es gibt PHP Projekte im Wasserfallmodell mit langem Lasten- und Pflichtenheft und es gibt Java-Projekte ohne jegliche Planung. Ist mir alles untergekommen.
PHP wird eher mal für ein kurzes Script genutzt, ok, aber der Beitrag bezog sich wohl auf Applikationsentwicklung mit PHP …
at johannes
das liegt nicht an der sprache selbst. full ack.
aber nach meiner erfahrung werden scriptsprachen gerne von der mittleren ebene, management so eingesetzt. ja es gibt grosse projekte mit vorarbeiten, lastenheft, pflichtenheft. da findet auch ein wandel statt desto mehr php, python in unternehmen eingesetzt und als professionelle werkzeuge aktzeptiert werden.
Ein ganz großes Problem von PHP im Vergleich zu Java ist, in meinen Augen, die fehlende Umsetzung der Typsicherheit, sowie der Initialisierung von Variablen.
Hier wird die Einhaltung einer der fundamentalsten Bestandteile von OOP allein in die Verantwortung des Programmierers gelegt, wogegen diese bei Javaprojekten für die angesprochenen Aspekte beim Compiler liegt.
Klar kann man auch unter PHP mittels Unittests oder mit der hier mehrfach angesprochenen Validiererklasse auf Typen prüfen, aber eigentlich könnte man sich diesen ganzen Käse sparen. Dann nämlich wenn ich einem Dollar nicht erst einen Integer, dann ein Auto und später ein Array zuweisen kann.
Beispielsweise if-Klauseln in Setter-Methoden a la „Hallo Wert – Bist du wirklich ein Integer?“ kosten nicht nur Zeit und gute Laune, sondern stören die Lesbarkeit, erhöhen die Fehlerquote, …
Ich denke man könnte hier eine Liste von Vorteilen anbringen, die eine Einführung der Typsicherheit und Initialisierung von Variablen mit sich brächte. Weiß da jemand mehr? Was wird aus PHP 6?
Ich seh OOP als einen Baustein von vielen, um effizient qualitativ hochwertige Applikationen zu entwickeln.
Andere Bausteine in dem Zusammenhang: Einsatz von Entwurfsmuster, Testgetriebene Entwicklung, Code Coverage, Coding Styleguides, Entwicklungsmethodik usw.
Also ein fortlaufendes Abwägen, was ins Repertoire aufgenommen wird, wo man sich weiterbilden will und was man am Besten wieder vergisst…
Bei mir wars eine natürliche Entwicklung, die irgendwann bei prozedural begann, weiterging zu Spaghetticode in Klassenmethoden usw.
Und die Frage, warum Softwareprojekte gar nicht, verspätet, in schlechterer Qualität fertig werden, führt dann irgendwann zur Beschäftiung mit Dingen wi npath complexity, kontinuierliche Integration usw.
@MiAsin woher hast du das bei Skriptsprachen das Zeitfenster kürzer veranschlagt wird, als bei anderen Sprachen wie Java oder C#? So richtig große Projekte außerhalb von C# hast du noch nicht umgesetzt oder? Deine Statements erinnern mich nen bisschen an das zum Teil heute noch andauernde PHP Bashing von Java Entwicklern… ohne dir was unterstellen zu wollen… 😉
Zum Artikel: Dem Autor kann ich da fast zustimmen, dass OOP Gegner immer wieder versuchen, die gute „alte“ prozedurale Programmierung im Unternehmen beizubehalten. Sitze im Moment an einem Projekt, welches seit zwei Jahren mehr oder minder nicht mehr weiterentwickelt wurde und seit 2003 eigentlich komplett prozedural programmiert wurde (hier mal ne Funktion, da mal nen SQL Statement mittem im Layout… – solchen unsauberen Kram kann man OOP technisch auch fertig bringen, aber OOP, aber man überwindet sich denn meistens doch den Code noch zu refaktorieren…), welches jetzt innerhalb von zwei großen Releases auf ein ordentliches OOP Gerüst gebracht werden soll. Den Kunden aber davon zu überzeugen, dass er auf lange Sicht mehr davon hat, als den vorhanden Kram „weiterzubehandeln“, hat mich ziemlich viel Zeit und vor allem Nerven gekostet…
Da kommen so viele Themen zusammen und werden nur oberflächlich angeschnitten. Seien es um zwei Programmierparadigmen, die sich gegenüberstehen (Vor- und Nachteile), ihre Einsetzbarkeit in verschieden großen (und skalierbaren) Projekten, die Eigenschaften der Scriptsprache PHP (bspw. Typsicherheit) oder php „best practice“.
Objektorientierung ist ein sehr umfangreiches Thema und ursprünglich ganz anders gedacht gewesen, als es heute in PHP umgesetzt ist. Auf jeden Fall kann man sagen, dass es einen Code weit aus verständlicher machen kann. Allerdings sehe ich in den letzten Jahren eine extreme Tendenz in der PHP-Welt, alles objektorientiert umsetzen zu müssen. Man findet kaum Artikel über Vorteile prozedualer oder funktionaler Programmierung in PHP, was ich sehr schade finde. Eigentlich sollte man von vornherein sagen, „es gibt kein besseres Paradigma“, schließlich haben sie stets Vor- und Nachteile und jeweils ihre Anhänger. Ich finde es kommt ganz stark auf den Zusammenhang des Einsatzes an, wann man OOP einsetzt und wann nicht. In PHP schadet es nicht einmal, Konzepte zu vermengen. Schließlich sollte auf der Prioritätenliste noch eine Sache viel weiter oben stehen: Keep it stupid simple. Niemand braucht eine super-skalierbare Anwendung auf strikten Standards und wunderbaren design patterns, wenn sie auch in einem Drittel der Zeit, mit der Hälfte an Arbeitskosten und genauso effizient umgesetzt werden kann – schließlich geht es darum dass „es läuft“ und nicht, dass ein Programmierer hinterher sagen kann „Hey, das ist alles objektorientiert und mit dem und dem Framework und den Standards und ..“.
Hinzu kommt meiner Ansicht nach, dass OOP oft knallhart erzwungen wird. Sagte ich OOP? Ich meinte wohl eher Implementierung von Klassen. Nicht alles ist als Klasse sinnvoll und durch Funktionen eben viel schneller und einfacher gelöst. Ich komme im Zusammenhang mit Datenbank-Modellierung (im MVC wohl das Model) ständig in Konflikt mit Konsistenz. Wenn ich ein Benutzer-Objekt habe, möchte ich möglichst kein zweites Objekt haben, das den selben Benutzer repräsentiert, denn sonst komme ich beispielsweise beim Cachen von Benutzereigenschaften in Konflikt (bzw. kann gar keinen Cache zwischen Datenbank und Logik mehr umsetzen). Ich müsste stets beim Abfragen von Benutzerdaten direkt die Datenbank ansprechen, auch wenn ich genau die Daten schon x-Mal ausgelesen habe. Möchte ich dagegen dafür sorgen, dass es nur ein solches Benutzer-Objekt gibt, muss es wieder eine Factory-Klasse o.ä. geben (bzw. einen Container), der genau für diese Eigenschaft Sorge trägt. In einer objektorientierten Welt denkt man an einen solchen Umstand zunächst eigentlich gar nicht. Da gibt es noch weit aus mehr Probleme, die auftreten, nur weil man versucht alles möglichst objektorientiert umzusetzen und am Ende steht man mit weit mehr Klassen da, als man ursprünglich gedacht hatte.
Da finde ich es oft befremdlich, wie sehr auf Objektorientierung gesetzt wird und fahre dann ganz gerne auch mal die funktionale oder besser gesagt prozeduale Schiene, da ich damit viel seltener auf solche (dafür auf andere) Probleme stoße.
Funktionale Programmierung kann genauso Code-sparend und Wiederverwendbar etc sein. Man muss es nur genauso wie ein objektorientiertes Projekt richtig durchplanen. Und es kommt stets auf den Fall an, welches Paradigma vorzuziehen ist. Niemand braucht für eine Hobby-Website eine dynamische Anwendung auf OOP-Basis mit Zend-/Flow3-/Symfony-/..-Framework. Da reicht eine wunderbare kleine, funktionale Welt. Und das impliziert nicht einmal, dass man nicht MVC umsetzen könnte oder HTML und PHP mischen muss. Leider bekommt man oft den Eindruck im Internet, dass für viele diese Begriffe einhergehen.
Zum Thema Typisierung und PHP 6 .. ich glaube nicht dass das umgesetzt wird, auch wenn ich das persönlich gar nicht schlecht fände. PHP ist gerade deshalb so erfolgreich, weil es eben dynamische Typisierung unterstützt. Und nicht umsonst findet man inzwischen auch sehr große Web-Anwendungen in PHP gecoded (Unternehmen setzen nicht mehr nur auf Java). Man kann sehr schnell entwickeln, es kostet wenig Aufwand, .. . Typisierung würde da vermutlich vielen Schwierigkeiten bereiten.
Ich hätte mir in dem Artikel noch ein etwas tiefer gehende Erörterung gewünscht .. und vielleicht einen provokativeren Schluss 😉
lG
Ich bin der Meinung, das es bei sehr kleinen Projekten wirklich unnötig ist, direkt die OOP-Keule zu schwingen. Aber sobald es groß und kompliziert wird, ist OOP etwas, worauf ich nicht mehr verzichten möchte.
Und es ist in der Tat so, dass es einfach zu wenig Infos über OOP unter PHP gibt, ich habe mich auch lange nicht dran getraut. Und sämtliche Bücher, die ich über PHP gelesen habe erwähnen OOP nur ganz am Rand oder widmen OOP nur ein halbes Kapitel. Da gibt es meiner Meinung nach viel Raum für Verbesserungen.
Ich würde mich freuen, wenn hier mal öfter OOP-Artikel erscheinen würden.
Es tut mir leid, dass ich erst so spät antworte – keine Unhöflichkeit, aber tagsüber kann ich leider nicht antworten.
@Chris
Gute Literatur zu dem Thema OOP und PHP ist etwas dünner gesäht. Ich persönlich würde mal einen Blick in “PHP objektorientiert” von Peter Lavin werfen, auch wenn es schon etwas älter ist und im ersten Kapitel noch PHP 4 behandelt.
Andere gute, mit bekannte Literatur zu dem Thema ist leider nicht für PHP.
Vielleicht hat noch jemand einen guten Tipp?
@Kim
Sprachen wie Java oder C# werden nach meiner (natürlich subjektiven) Erfahrung anders bewertet (gar nicht so sehr von den Entwicklern), da sie wie auch MiAsin geschrieben hatte eher in einem „professionellen Business-Umfeld“ gesehen werden (was immer das auch sein soll 😉 und allein deshalb längere Projektlaufzeiten akzeptiert werden.
Bei PHP – wie bei vielen Skriptsprachen – geht ja alles „mal eben so“.
Das liegt kaum an den Sprachen oder den umgesetzten Projekten, schon gar nicht an PHP.
@Igor
Das fasse ich auch gar nicht böse auf 🙂
Ich nehme das als Hinweis zukünftig einen aussagekräftigeren Titel zu wählen und zu versuchen den Beitrag mehr auf den Punkt zu bringen.
Ich denke ein einführendes Tutorial über OOP unter PHP wäre nicht das was die Leser dieses Blogs erwarten würden, ansonsten schreibe ich eines – versprochen!
@Renner
Hier muss ich widersprechen. Auch wenn die nicht zwingende Initialisierung von Variablen eine beliebte Fehlerquelle ist – weder starke noch statische Typisierung ist ein Merkmal der OOP.
Ich persönlich bezweifle auch nach wie vor, dass eine starke/ statische Typisierung mehr Sicherheit bringt oder die Lesbarkeit erhöht.
Zum Thema Lesbarkeit:
Das ist natürlich Geschmacksache, aber ein Quellcode, der gespickt von für den Algorithmus unrelevanten Zeilen ist, ist in meinen Augen schlechter lesbar.
Typüberprüfungen, wie oben bereits beschrieben, zählen da meines Erachtens zweifelsohne zu dieser Gruppe. Da man seine Variablen auch unter PHP initialisieren sollte, ensteht da auch kein großer Overhead, wenn man noch eben den Typ vor den Variablennamen setzt.
Auch erhöht es das Leseverständnis, wenn der Typ einer Variable sich nicht – zumindest lokal in der Methode / Schleife – verändert.
Zum Thema OO und Typisierung:
OO ohne Typisierung bedeutet für die Einhaltung von OO eine kann-Norm.
Zudem ist es wiederum die Lesbarkeit. Der vollständige Verzicht auf Typisierung an den wichtigen Stellen Initialisierung von Variablen, Attribut- und Methodendeklaration, sowie Type Hinting von Parametern macht größere OO-Projekte zu unwartbaren, bei den zuständigen Entwicklern Angst auslösenden, fehlerträchtigen Müllkippen. Was natürlich wiederum Geschmacksache ist.
Klar kann man da mit DocBlocks und Unittests einiges auffangen, aber der Aufwand ist meines Erachtens, vor allem bei Änderungen und/oder Refactorings ungleich höher.
@Chris
schau dir mal von Stephan Schmidt das Buch „PHP Design Patterns“ an.
Das sollte dir weiterhelfen, auch wenn das Beispiel eine Autovermietung ist 🙂
@Renner
Ich muss noch einmal widersprechen 😉
Late binding ist ein zentraler Punkt der OOP und statische/ strenge Typisierung läuft dem entgegen.
Nur weil einige OOP-Sprachen nicht dynamisch typisiert sind, ist das noch lange nicht richtig geschweige denn besser.
Auch bezweifle ich stark, dass dynamische Typisierung „Angst auslösende, fehlerträchtige Müllkippen erzeugt“.
Gerade unter dem strengen Typsystem von C# habe ich die dynamische Typisierung von PHP schätzen gelernt.
Ich möchte ehrlich gesagt kaum eines meiner PHP-Projekte mit einem statischen Typsystem programmieren müssen 🙂
@Stephan:
„Ich denke ein einführendes Tutorial über OOP unter PHP wäre nicht das was die Leser dieses Blogs erwarten würden, ansonsten schreibe ich eines – versprochen!“
Erm, *meld* 🙂 Ich hätte gerne ein solches Tutorial.
Der Punkt ist, dass ich theoretisch die proklamierten Vorteile verstehe (Kapselung, Wiederververwendbarkeit, bessere Wartung des Codes in Teams, etc.), jedoch kein praktisches Beispiel zu finden ist, was genau jetzt besser/schlechter in OOP gegenüber den prozeduralen Programmieransatz ist.
Zudem helfen, wie Chris bereits erwähnt hat, die klassischen OOP-Lernbeispiele (Klasse: Auto, davon werden die Objekte: Ford, Opel und VW abgeleitet; nun definieren wir Methoden wie „beschleunigen()“ usw.) nichts, wenn man sich faktisch mit Webseiten-Entwicklung beschäftigen will. Da hat man nun äußerst selten ein Auto zu modellieren.
@Philipp
Nicht böse sein, aber bei einer Anfrage lohnt es sich leider noch nicht ein solches, umfangreiches Tutorial zu schreiben.
Ein gutes Beispiel oder Tutorial (worauf es immer hinauslaufen würde) hat mit den üblichen Problemen zu kämpfen:
– Die Vorteile der OOP zeigen sich mehr bei großen Projekten, idealerweise wenn mehrere Personen beteiligt sind (Beispiele und Tutorials sind zwangsläufig eher kurz zu gehalten).
– Die OOP spielt ihre Stärken aus, wenn es zu tiefer greifenden Änderungen der Anforderungen kommt.
– Besonders wenn Code nach längerer Zeit überarbeitet werden muss, geht dies mit gutem OO-Code leichter.
Ein passendes Tutorial wäre sehr umfangreich, da man den prozeduralen Code dem OO-Code gegenübergestellen und idealerweise Änderungen der Anforderungen mit einem beispielhaften Umbau entwicklen müsste.
Das würde hier höchstens für den akademischen Tag in mehreren Teilen passen, aber könnte auch sehr ermüdend sein wenn es wirklich in die Tiefe geht.
Viele klassische OOP-Lernbeispiele, die auf einer Abbildung der Realität basieren, sind bestenfalls geeignet Klassen und Objekte als grundsätzliches Konzept zu erklären. Ich frage mich sowieso wer jemals angefangen hat zu postulieren OOP solle die Realität in der Programmierung abbilden? Daran krankt meineserachtens die OOP und das Suchen der geeigneten Klassen wird damit unnötig erschwert.
Ich würde auch gerne so ein Tutorial haben. So von meiner Seite auch eine Meldung!
@Julian: Funktionale Programmierung und prozedurale Programmierung sind zwei sehr unterschiedliche Dinge.
Zum Thema: Neulich bin ich auf ein Zitat [1] (von Paul Graham) gestoßen, das auch hier, wenn auch in abgeschwächter Form, genannt wurde: „Object-oriented programming is popular in big companies, because it suits the way they write software. At big companies, software tends to be written by large (and frequently changing) teams of mediocre programmers. Object-oriented programming imposes a discipline on these programmers that prevents any one of them from doing too much damage. The price is that the resulting code is bloated with protocols and full of duplication. This is not too high a price for big companies, because their software is probably going to be bloated and full of duplication anyway.“
[1] http://www.paulgraham.com/noop.html
@stephan elter
oop funktioniert doch in allen fällen besser als prozedurales zeug. einmal auf dem oo-zug blick doch niemand mehr zurück – so geht´s zumindest mir.
auch wenn ich von vornherein weiß, dass ein programm wohl nicht besonders groß wird, verwende ich klassen. an dieser stelle zurück auf prozedurale programmierung zu fallen hat meines erachtens keine vorteile – ganz im gegenteil: oop besteht ja implizit aus prozeduralen konzepten (kapselung von daten; modularisierung; funktionen verändern einen zustand) aber eben mit sinnvollen erweiterungen und verfeinerungen.
den hinweis, oop bilde die realität ab finde ich für als einstieg gar nicht schlecht – es erklärt doch in einem satz das, worum es im wesentlichen geht. du hast natürlich recht, die richtigen klassen identifiziert man damit noch lange nicht.