Anfängliches Programmieren ist wie Gartenhäuschen bauen

Gutes Pogrammieren ist wie schöne, verzierte Gartenhäuschen bauen

Professionelles Programmieren ist wie Hochhäuser bauen

Dies habe ich am Mittwoch, als ich den Uni für Einsteiger Tag in Karlruhe besucht habe, bei einem Professor für Informatik in einer Präsentation gesehen und es gefällt mir sehr gut, weil es bestens auf das Problem hinweist:

Hochhäuser sind keine großen Gartenhäuschen!

Beim Hochbau muss man noch viel mehr Statik und weitere Probleme beachten und beim Programmieren ist das nicht anders. Man kann – selbst mit gutem Code – nicht so einfach große Projekte aufziehen.

Ich lerne momentan den Hochbau und hoffe mit diesen Kenntnissen ein ansehnliches Haus hochziehen zu können. Sobald das steht, wird es wieder einfacher, die Verzierung eines Hochhauses wird wohl nicht schwieriger als das eines Gartenhäuschens und ich werde Hilfe brauchen, denn es wird viel zu tun geben.

Nun zu meinen neuen Entwurf

Wer noch den zweiten Entwurf kennt wird sich wundern, weil ich ein paar Sachen umbenannt habe. DataHandler heißt nun Service und Model Phlame, Sub oder Modul.

Ich bitte nun die, die nicht den zweiten Entwurf kennen, einen Blick darauf zu werfen, damit ich diesen Teil nicht wiederholen muss. http://ugamela-blog.pheelgood.net/2008/09/26/phlame-engine-der-entwurf-nr2/

Diagramm zum dritten Entwurf

Der Requester (mir fällt kein besserer Name ein) führt die Abfragen gegen die Datenbank aus. Zwischen den Requester und den Service wird ein Cachemechanismus mit der Session gebaut (der Requester wird dekoriert). Das sollte einige Queries einsparen. Auch das Datenbankupdate wird selbständig und querysparend vom Requester übernommen. Pro Tabelle gibt es einen Requester.  Modul-, Sub- und Phlamerequester unterscheiden sich wahrscheinlich an ein paar Stellen. Gleichzeitig dient der Requester als Spiecher für Queryschablonen für die jeweilige Tabelle. Wahrscheinlich lässt sich auch durch austauschen der Requester die Datenbank wechseln (auf PostgreSQL zB), aber vorerst habe ich nur MySQL mit mysqli vorgesehen.

Der Service wird – im Gegensatz zum Requester – vom Programmierer direkt angesprochen und ist einmalig überall verfügbar (Singleton). Er verwaltet die Instanzen eines Objektes, die im Umlauf sind, und ruft den Requester auf. Das packen der Datenarrays in Objekte geschieht im Service bzw. in der Fabrik, mit der Phlame, Sub, Modul oder einer entsprechenden abgeleiteten Klasse.

Phlame (Flamme oder Flämmchen zu deutsch^^, nicht von Belang) ist eine Vorlage für diverse Objektformen, die von dieser Klasse abgeleitet werden können. Das bedeutet sie enthält ein paar Vorgaben, wie ein solches Spielobjekt auszusehen hat. Vorgesehene Ableitungen sind Sonnensystem (auch bekannt als Planeten..) und Flotte.

Sub ist eine Untergruppierung von Phlame. Der Aufbau ist der selbe wie beim Phlame selbst, nur das der Service vom Phlame-Service oder der Fabrik aufgerufen wird, der die Subs in das Phlame schachtelt. Vorgesehene Ableitungen sind Schiffe und Gebäude.

Modul ist Sub sehr ähnlich, stellt aber nur einzelne Eigeschaften von Sub oder (weniger) Phlame dar (die Verbindung zu Phlame ist im Diagramm nicht angezeigt). Der Service wird also vom übergeordneten Service oder der übergeordneten Fabrik aufgerufen und die Module werden in das übergeordnete Objekt geschachtelt.

Resultat sollte ein ORM Schema sein. Phlames sind Objekte mit Unterobjekten, die automatisch (ohne Serialisierung) in der Datenbank gespeichert werden. Dadurch lässt sich übrigens auch weiterhin ohne die Objekte arbeiten, vor allem MySQL intern.

Benötigen tue ich dieses Schema vor allem für sehr variable Kämpfe, also Objektinteraktion und einfach freiere Modellierung der Objekte selbst und ihren Beziehungen zu anderen im Spiel.

Framework.. vor ein paar Monaten hab ich noch Gedacht damit ist der Plan oder die Vorgehensweise für ein Projekt gemeint, dem ist aber nicht so. Ein Framework ist eine Bibliothek aus Scripten, auf der man ein Projekt aufbauen kann. Dies beinhaltet vor allem Grundfunktionen und geben bereits eine MVC Struktur vor.

Nun ein paar Frameworks, die ich mir angesehen habe:

Das Zend Framework erschlägt mich fast mit seinem Umfang. Es führt auch sehr viele Sachen, die ich überhaupt nicht brauche. Es ist meiner Meinung nach ein Schwergewicht. Ich habe keine Tests gemacht, aber ich kann mir denken, dass das ganze trotz direkter Einbindung auf dem Server (keine PHP Scripte) nicht so performant wie ein kleines leichtgewichtiges Framework ist. Ich verwende es aus dem selben Grund nicht, wieso ich Smarty nicht verwende – ich brauche diese Schwerfälligkeit nicht, so praktisch sie auch sein kann, sondern brauche etwas Leichtgewichtiges, das gut auf meine Zwecke zugeschnitten ist.

Das PHP Framework symfony gefällt mir schon besser, obwohl die Dokumentation nur auf Englisch ist. Vor allem ist ORM mit Propel möglich. Nach näherem Hinsehen kann Propel zwar einiges, was ich gebrauchen könnte oder selbst gar nicht schöpfen werde/würde, doch eine sehr wichtige Eigenschaft fehlt mir: Row-Level-Locking, ein Schreibschutz auf bestimmte Tabelleneinträge, der auf InnoDB Tabellen in MySQL viel besser ist als das bekannte “LOCK TABLES” auf MyIsam Tabellen. Aus diesem Grund kann ich Propel, mit oder ohne Symfony nicht verwenden.

Ich falle zurück auf die Idee ein eigenes, sehr leichtgewichtiges Framework zu schreiben.

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.