Manchmal ist es ganz gut, kein Streber zu sein. Aber darum geht es eigentlich nicht, denn Klassen gibt es nicht nur in der Schule, sondern auch in der Programmierung. Bisher habe ich die objektorientierte Programmierung in PHP vermieden. Nicht, weil ich es nicht kann, sondern weil es keine Notwendigkeit dafür gab. Etwas komplizierter machen, nur um sagen zu können, dass es objektorientiert ist, liegt mir nicht.
Wenn ich schreibe „bisher”, dann impliziert das eine Änderung. Die gibt es tatsächlich. Aktuell sind bei myGallery eine Menge Probleme in Bezug auf die Navigation innerhalb von Galerien aufgetreten. Es gibt eine größere Anzahl an Fällen, die zu berücksichtigen sind (Galerieübersicht auf mehrere Seiten verteilt, nur x Thumbnails pro Seite, Thumbnails in der Großansicht etc.).
Die Anzahl der Variablen und deren Übergabe wurde im Skript immer unübersichtlicher, so dass es auf der Hand lag, dafür eine Navigationsobjekt zu verwenden, dessen Eigenschaften und Methoden wesentlich einfach zu verwenden sind.
Das ist das auch einer der Gründe, warum es momentan um die nächste Version von myGallery etwas ruhiger geworden ist. Ich bin dabei, einige grundlegende Änderungen vorzunehmen, die nach außen nicht unmittelbar sichtbar sind. Das und die Tatsache, dass es in der aktuellen Version noch einige Fehler gibt, führten bei mir dazu, einen Entschluss zu fassen, der die kommen myGallery Version betrifft.
Aus meiner Sicht ist es das Beste, erstmal keine neuen Features mehr für die kommenden Version 1.3 einzubauen, sondern die bisher aufgetretenen Fehler nahezu vollständig zu beseitigen. Daher wird es, auch wenn es schade ist, erstmal kein Wasserzeichen und keine extra 3D-Effekte geben (danke noch mal an die, die mir die Skript-Vorschläge geschickt haben – sie werden auf jeden Fall der 1.4 Version berücksichtigt).
Ziel ist es, Version 1.3 innerhalb der nächsten zwei Wochen zu veröffentlichen, auch um das Murren an der Basis zu beruhigen. Danach wird es dann eine Screencast geben, der die beide Wege zur Erstellung einer Galerie noch mal erklären soll. Wenn das geschafft ist, werde ich mich der Version 1.4 und eine Überarbeitung der Dokumentation zuwenden.
Stichwort Dokumentation: Das es bisher noch keine neue Dokumentation gibt, liegt daran, dass sich wesentliche Elemente des UI verändern, sogar verbessern werden. Da ich ich nicht zwei Mal in kurzer Zeit die Dokumentation neu schreiben möchte, wird diese also erst angegangen, wenn das User Interface überarbeitet wurde.
5 Kommentare
Wenn es mit Objekten komplizierter wird, läuft etwas falsch. Der Sinn von objektorientierter Programmierung ist eigentlich die Vereinfachung von Quelltext und von Abläufen. Und in allen Projekten an denen ich bisher gearbeitet habe, ging das Konzept auch auf. Das schwierigste an ooP ist mit Sicherheit die Erfahrung zu erlangen um von der falschen Denkweise ‚Auto ist die Klasse, Reifen sind ein Attribut und fahren und bremsen sind die Methoden‘ wegzukommen. Dies wird häufig in den Büchern so erzählt und ist halt ein sehr simples Beispiel. Wenn man sich daran hält hat man zwar Klassen, die sind jedoch sehr groß und haben eigentlich nichts mit ooP zu tun. Eher mit ’normaler‘ verpackt in ein Objekt. Wenn ich dir da irgendwie bei helfen kann, frag einfach. Das ist nämlich genau die Thematik mit der ich mich tagtäglich beschäftige.
Was ich im Artikel zum Ausdruck bringen wollte: In PHP reicht eine einfache Funktion oft aus – da muss nicht unbedingt eine Klasse zu geschrieben werden (meine ich jedenfalls). myGallery besteht bisher eigentlich nur aus Funktionen. Der Sinn von OOP ist neben der Flexibilität und Widerverwertbarkeit für mich, eine einfacher zugängliche Schnittstelle zu haben.
Für Tipps in Bezug auf OOP bin ich immer zugänglich. Ich habe mich mit dem Thema zu lange nur am Rande beschäftigt. Gewisse Sachen beleiben zwar im Kopf hängen, andere Aspekte aber eben nicht. Das Auto-Beispiel kenne ich (leider) auch – das prägt leider sehr und verhindert eine andere Sicht auf OOP.
O.T.: Wie schaut’s mit dem Webmontag aus?
Das man mit Funktionen ans Ziel kommt ist bei jeder Sprache so, die Vorteile von Objekten kommen dann ins Spiel wenn man durch austauschen von Klassen zur Laufzeit das Verhalten des Programmes ändern will. Wenn man sowas liest meint man das wäre nur was für ganz heiße Sachen und im ’normalen‘ Leben braucht man sowas nicht. Die Erfahrung zeigt aber das in langlebigen Projekten, also Sache die nicht Fire and Forget sind, kein Weg um ooP führt. Weil nur Funktionen führt auf Dauer zu Spaghetti Code. Deswegen sind ja alle Sprachen die heute neu auf den Markt kommen komplett objektorientiert. Sei es .Net, Ruby, Java oder sonstwas. PHP ist eine der wenige Sprachen der letzten Jahren die Objekte erst nachher eingeführt haben. Liegt wahrscheinlich daran das PHP nur ein Internet Perl war zu Anfang.
Ach ja, @Webmonat. Beim nächsten werde ich wieder dabei sein. Da können wir das Thema gerne mal aufgreifen. Gerne sonst auch mal außer der Reihe zwischendurch bei einem Bierchen :)
Mhm, bei webmontag steht jetzt 17. Juli – aber der ist schon vorbei. Merkwürdigst. Das außer der Regei mit Bier hört sich gut an :-)
Vermutlich liegt es bei mir in Bezug auf OOP auch dran, dass ich mit Pascal, Fortran & Co angefangen habe (vor langer Zeit). So was prägt. Der erste Kontakt mit OOP war dann Java und Lingo (woebei da OOp sehr einleuchtend war, weil es darum ging, Spielobjekte zu basteln).
Bei Java ist mir auch klar, dass OOP sinnvoll ist, da die Objekte ja zur Laufzeit im Speicher bleiben. Bei PHP sehe ich einfach nur den sequenziellen Ablauf nach dem Aufruf der Seite. Sobald die Seite angezeigt wird, ist das Skript auch beendet und das Objekt (wenn nicht in Form eines Cookies oder ähnliches gespeichert) weg.