nicht angemeldet
Moin!
Ich hätte von euch gerne mal ein paar Statements zu den Begriffen:
Interfaces,
Eine sehr schöne Methode, die Implementierung von definierten Methoden in unterschiedlichen Klassen zu garantieren, und dennoch Type-Hinting in der Parameterliste der diese Objekte nutzenden Methode sicherzustellen.
Interfaces will man haben. Insbesondere will man die Interfaces der SPL implementieren, wenn man sie braucht. Typischer Interfaces wären Countable, Iterator und ArrayAccess.
Vorteil von Interfaces ist, dass man in einer Klasse auch mehrere von ihnen implementieren kann - aber nur eine einzige Klasse unter "extends" angebbar ist. Dafür liefern Interfaces keinerlei Code der Methoden, die sie definieren.
Interfaces sind eine sehr schöne Sache, wenn man den Bedarf für sie erkannt hat.
Namespaces,
Irrelevant, solange PHP 5.3 noch keine ausreichende Verbreitung gefunden hat, und man es selbst nicht nutzen kann.
Polymorhie, Mehrfachverehrbung
Irrelevant für PHP, da nicht verfügbar.
und ihrer Rolle in PHP Skripten, Selfmade Frameworks, großen Webprojekten usw.
OOP ist ab einer gewissen Projektgröße aus einem einzigen Grund notwendig: Um die Übersicht zu behalten, komplexe Programmstrukturen zu vermeiden bzw. das insgesamt komplexe System in einfache Untereinheiten zu zerteilen, und das Duplizieren von Code zu vermeiden.
Frameworks sollte man nicht selbst schreiben. Bzw. sollte jeder Entwickler irgendwann mal ein Framework selbst schreiben - aber nur, um die Erfahrung zu machen, was zum Schreiben eines Frameworks alles dazugehört, nicht um es danach auch noch produktiv einzusetzen.
Meiner Ansicht nach raubt das fast alles nur Performance und bisher benutze ich sie nicht. Ich weiß einfach nicht wann diese Dinge wirklich SINN machen - ab wann macht es Sinn sie einzusetzen?
Du kannst alle deine Aufgaben grundsätzlich prozedural erledigen, keine Frage. Schließlich wird jegliche Objektorientierung irgendwann immer von einer sehr dummen CPU ausgeführt, die nur die ganz elementarsten Byteschiebeoperationen kennt - auf diesem Level betrachtet ist Objektorientierung also nicht existent, mit Ausnahme der zusätzlichen, sinnlos erscheinenden Operationen, die zusätzlich durchgeführt werden.
Objektorientierung hat nur einen einzigen Sinn: Dem Programmierer erleichtern, nicht nur einfache Aufgaben zu programmieren, sondern auch komplexe Aufgaben zu lösen. Denn die Objektorientierung erlaubt es, eine komplexe Aufgabe in viele einfache Teilaufgaben zu zerteilen, die Lösungen dieser Teilaufgaben in Objekten zu verpacken und die verpackten Lösungen dann, ohne Betrachtung ihrer Details, zur Lösung größerer Probleme zu verwenden.
Die Verpackung von Lösungen in Objekten ist dabei der zentrale Aspekt, denn er erlaubt es, sich jeweils nur auf das konkrete Problem konzentrieren zu können, indem man sich z.B. ein Objekt erschafft, welches gewisse Dinge komplett erledigt, und auf einer höheren Ebene dann nur noch in einer Programmzeile diese Methode aufruft, ohne den gesamten Quelltext an dieser Stelle sehen zu müssen.
Objektorientierung ist allerdings dann doch noch mehr, als nur das Schreiben von Funktionen. Die Erzeugung der richtigen Objekte, ihre Ausstattung mit den richtigen Daten sowie die Zusammenstellung der passenden Objekte innerhalb eines übergeordneten Objekts sind die Dinge, die man erst mit einer gewissen Erfahrung lernt.
Es hilft dabei übrigens, sich auch über das Testen der eigenen Software mal Gedanken zu machen bzw. sich Ausführungen zum Thema "Testbarer Code" zu Gemüte zu führen. Testbaren Code zu schreiben erlaubt nicht nur, ihn zu testen, sondern stellt gewisse grundsätzliche Forderungen auf, die dazu führen, dass der Code leichter lesbar und wartbar bleibt.
- Sven Rautenberg
Der Martin