UGamela Blog

ORM wird größtenteils den Kern meines Frameworks darstellen.

Nur, was ist ORM? [Ich meine hier übrigens nicht Objekt Role Modeling, das auch ORM abgekürzt wird]

Ich muss vorwarnen, das wird jetzt wahrscheinlich für den Großteil der Blogleser unverständlich. Es gehört wohl zu den Tiefen des Programmierens, neben den Entwurfsmuster. Oft wird hier mit Fremdwörtern nur so um sich geschmissen. Ich habe immernoch so meine Probleme, so lange mache ich das ja noch nicht. Ich werde mich trotzdem bemühen es einfach auszudrücken.

Relationale Datenbanken, wie MySQL, legen Daten in Tabellen ab. OOP arbeitet aber mit Objektinstanzen. ORM soll nun das Zwischenstück bilden, das die Objekte in der Datenbank abbildet. Ich möchte mittlerweile nurnoch mit Objekten arbeiten, es vereinfacht das Programmieren ungemein. Ich möchte vor allem Spielelemente wie Flotten als Objekte verwalten, um besser Interaktionen zu überblicken. Doch bevor man sich bei jedem Objekt mit dem Speichern in der Datenbank herumschlagen muss, möchte ich das lieber in verschiedenen (Abstraktions-)Schichten verstecken. Für die „Community-Entwickler“, die hoffentlich nach Fertigstellung des Frameworks tatkräftig mithelfen ein Spiel zustande zu bringen, bedeutet dies, dass ein Haufen Arbeit wegfällt. Dafür müssen sie sich halt mit (relativ einfachen) Klassen herumschlagen, was sie vielleicht von PHP noch nicht gewöhnt sind.

Ganz nebenbei wird dann übrigens gecacht und Race Conditions umschifft, ohne dass man etwas davon mitbekommt. OOP hat den großen Vorteil, dass man anderen Code nicht kennen muss, man muss nur wissen was er tut, und dafür gibt es die Dokumentation.

Vor ein-zwei Monaten habe ich Entwurfsmuster – in PHP – kennengelernt, obwohl ich davor schon viel früher über sie gestolpert war, hatte ich sie irgendwie nie richtig wahrgenommen oder einfach nicht verstanden.

Wenn Programmieren abstrakt ist, dann sind es Entwurfsmuster erst recht. Die Beschreibungen der Muster sind gar so abstrakt, dass man umbedingt Beispiele für die Anwendung braucht.

Auch wenn man sie leicht übersieht, stehen bereits im PHP Handbuch zwei Entwurfsmuster. Singleton und Fabrik. Ich möchte auf Singleton eingehen, hole aber noch etwas weiter aus.

Ich habe mich, als ich OOP anfing, gewundert wofür die public, protected und private Deklarationen sind und denn Sinn einfach nicht verstanden. In PHP dienen sie größtenteils gar nicht dem Programmierer selbst, sondern anderen Programmierern, die am selben Projekt schreiben. Sie schließen einfach die falsche Verwendung aus und kapseln Funktionen und Eigenschaften durch die Zugriffkontrolle. Für die Codefunktionalität sind sie somit unwichtig. Man könnte auch einfach alles public deklarieren, wenn man es trotzdem richtig verwendet (PHP4 ist noch alles public).

Singleton geht auf diesem Weg weiter, er erlaubt nur eine Instanz eines bestimmten Objektes, auf welche gleichzeitig global zugegriffen werden kann.

Das benötigt man zum Beispiel bei der Datenbank, die meist nur eine einzige Verbindung umfasst.

http://docs.php.net/manual/de/language.oop5.patterns.php

Es gibt aber noch viele andere komplexere Entwurfsmuster. Ich werde demnächst nochmal das neue Schema für mein Projekt erklären.

Entwurfsmuster zählen definitiv zur Professionellen Programmierung, das Niveau ist deutlich anders, als das simple Programmieren von einfachen Websites.

Seit PHP4 ist es möglich PHP OO zu programmieren. Mit PHP5 wurde das stark ausgebaut, aber bisher habe ich noch kein OS (Open Source) Projekt gesehn, in dem das wirklich verwendet wird, dabei ist das doch nun schon älter… PHP geht schon in Richtung PHP6…

Ich habe mich sofort für OOP begeistern können, als ich es kennenlernte, auch wenn mir das nicht leichter fällt als prozedural (das ist der andere PHP Stil den quasi alle praktizieren) zu programmieren.

Yeah, PHP OOP ist supertoll, das muss ich ab jetzt umbedingt immer verwenden!
→ Nein! Man muss eindeutig abwiegen, ob man etwas OO programmiert, den bei PHP geht dabei Performance verloren, denn das kompliieren dauert länger.

Zum Preis von einem bischen Performance bekommt man dafür:

• Übersichtlichkeit / Lesbarkeit
• Darstellung von abstrakten und realen Dingen
• Erweiterbarkeit
• Wiederverwendbarkeit
• Kapselung
• und somit Effizienz

Und diese Liste ist noch lang nicht vollständig.

Das hat mich letztlich überzeugt. Ich bin dabei das Herzstück („Phlame Engine“) für UGamela in OOP zu schreiben. Dabei werde ich zum Beispiel Planeten und Flotten in Models abbilden. Das Ergebnis gibt den Moddern, die hoffentlich angespornt sind und viele Ideen haben, einfache Möglichkeiten mit den Daten umzugehen, wahrscheinlich ohne selbst Ahnung von MySQL oder Sessions zu haben.

Ihr könnt ich somit schon auf die PHP OOP Pfeilchen „->“ freuen xD