Wir hatten im Dezember ja schon mal eine Folge MeinPHP auf die Leser losgelassen. Bei MeinPHP geht es eigentlich darum eine Aufgabe, die wir stellen möglichst elegant zu lösen und in seinem Forum, Blog oder woanders zu Posten. Ich habe lange überlegt, was man als nächste Herausforderung machen könnte. Und heute kam mir endlich die Idee.

PHP ist meine bevorzugte Sprache, wir ihr ja vielleicht wisst, nichtsdestotrotz kann man echt fiese Sachen damit bauen und das schlimmste daran ist, man findet diese fiesen Sachen immer wieder in produktiv eingesetzten Tools. Und warum? Weil man es kann! (Danke Olaf für die Aussage). Aus diesem Grund möchte ich heute einen kleinen Contest ausschreiben. Wer kann das fieseste Skript basteln?

Meine Theorie ist ja, dass in einem wirklich schrecklichen Programm mindesten ein goto, ein catchable fatal error, ein class_alias, ein $$ und vielleicht ein wenig Reflection dabei sein muss. PHP 5.3 hat echt ein paar schöne “Monster” mitgebracht, die in den falschen Händen schon ganz schön Schaden anrichten können. Ich selbst werde mich auch daran probieren, habe da auch schon ein paar Ideen.

Anders als beim letzen Mal werden wir keine konkrete Aufgabe aussuchen, seid also kreativ und versucht euch selbst zu schocken. Ich denke mal, dass so zwei Wochen reichen sollten, um was wirklich gemeines zu zaubern. Solange habt ihr also Zeit euch was auszudenken. Wem was eingefallen ist, der kann es mir gerne per E-Mail schicken oder am besten einfach bei sich im Blog zu posten. Nach dem Ablauf der Frist werden wir dann das beste schrecklichste Skript kühren und den Titel “PHP Teufel” verleihen.

Oft hilft es übrigens auch sich den eigenen alten Code anzuschauen. Zumindest bei mir. Viel Spaß also mit der Aufgabe, ich werde ihn haben.

Im ersten Teil habe ich euch von den eingegangenen Lösung berichtet, im zweiten kurz skizziert, wie wir uns die “Musterlösung” vorstellen. Heute möchte ich die tatsächliche Implementierung zeigen. Da es etwas mehr Code geworden ist, als wir gedacht haben, werde ich unsere Klassen einfach in eine externe Datei packen. Ich werde auch nur auf die relevanten Stellen eingehen, da es sonst zu aufwendig werden würde.

Fangen wir also an. Ich hatte mich ja bei den anderen Lösungen “beschwert”, dass alle in O(n) ihre Elemente einsortieren. Es verdoppelt sich also der Aufwand, sobald die Anzahl der Elemente sich verdoppelt. Verwendet man einen normalen Array mit den natürlichen Zahlen als Index, dann hat man eben das Problem, dass sie nach der Reihenfolge, wie sie dem Set hinzugefügt wurden in dem Array liegen. Natürlich muss ich so das Array komplett durchgehen, bevor ich mein Element finde. Wenn aber jedem Element ein spezieller Hashwert zugeordnet wird, der die Position im Array definiert, so reduziert sich meine Suche auf ein Feld. Dieser Hashwert wird bei uns über spl_object_hash berechnet, da dieser eindeutig ist und für jedes Objekt bereits existiert. Nutzt man diesen jetzt als Schlüssel im Array, so verringert sich die Komplexität von O(n) auf O(1) . Das gilt natürlich nur, wenn PHP intern Hashmaps verwendet, um den Zugriff auf einen Array zu gewährleisten. Könnte man ganz einfach testen, in dem man schaut auf der Zugriff ein ein Array mit 10 Elementen genau so lange dauert, wie bei 10.000.

Dieses Problem haben wir also beseitigt. Den Rest haben wir sehr ähnlich den anderen Lösungen gemacht, die wir ja bereits auseinander genommen haben. Wir haben is_a verwendet, anstatt über get_class und “==” zu vergleichen, haben uns an die Java Collection angelehnt und das “Separation of Concerns” Paradigma befolgt, haben mit Interfaces hantiert und einen Dekorierer erstellt, damit wir über Delegation arbeiten können und nicht die Vererbungshierarchie verändern, haben unsere eigenen Exceptions verwendet. Ansonsten sind die Lösungen relativ ähnlich.

Wenn man sich unsere Lösung anschaut, dann mag sie anfänglich ein wenig komplexer wirken, als die anderen. Ich meine wir haben fast 220 Zeilen Code geschrieben. Dafür sind aber die einzelnen Klassen wiederverwendbar und nicht sonderlich komplex. Bei der Entwicklung einer typsicheren Liste z.B. wäre unsere Arbeit relativ schnell getan und er “Mehraufwand” hätte sich bereits gelohnt.

Bis jetzt ist die Lösung nur ein Prototyp und wir haben ihn, wenn ich ehrlich bin auch noch nie getestet. Es ging uns ja auch eher um den theoretischen Ansatz. Die lauffähige Version werde ich die nächsten Tage online stellen. Ich wollte es anfangen meine Klassenbibliothek mal öffentlich zugänglich zu machen, vielleicht hat ja der ein oder anderen einen nutzen daran.Ach ja, wenn ihr Fragen habt zu unserer Lösung, dann könnt ihr die jeder Zeit hier stellen. Ihr bekommt auch garantiert eine Antwort.

So ich hoffe euch hat diese kleine Herausforderung Spaß gemacht. Mir hat es das auf jeden Fall und aus diesem Grund wird es auch bald einen neuen Contest geben, in dem ihr zeigen könnt, was ihr drauf habt.  An dieser Stelle möchte ich mich auch noch einmal bei unset, Sebastian, Timo, Schwobeseggl, Schaelle und Andy G. bedanken. Ich hoffe ihr seid das nächste mal auch wieder dabei.

Zu Beginn betrachten wir uns die Hilfsmittel, die PHP uns von Hause aus mitgibt. Wie es ja schon einige von euch gemacht haben, haben wir uns die, unserer Meinung nach, die best passendste Schnittstelle aus der SPL als Grundlage genommen. Dem Iterator Interface. Wichtig war uns, dass wir das Set später ganz einfach durchiterieren können, um so auf alle Elemente zugreifen zu können, die vorhanden sind. Und genau dies macht ein Iterator.

Getreu nach dem Paradigma “Separation of Concerns” brauchen wir jetzt noch eine Klasse, die dafür sorgt, das Daten vorgehalten werden können. Wir haben diese Klasse Collection, in Anlehnung an die Java Klasse,  genannt. Ein schönes Interface drumrum und alles bestens.Wir können jetzt also durchiterieren und Daten sammeln. Wichtig war uns, dass wir die Collection unabhängig vom Set verwenden können.

Im nächsten Schritt wollen wir das Set, eine spezielle Collection kreieren. Dafür leiten wir die Collection ab und verbieten, dass ein Element mehrmals vorkommen kann. Der letzte Schritt, ist die Typsicherheit. Hier haben wir uns für das Decorator Pattern entschieden. Uns war wichtig, dass dieses spezielle Set auch mit anderen Einschränkungen kombiniert werden kann.

Als Klassendiagramm sieht es also wie folgt aus:

Dass viele der Methoden einer Collection einen boolschen Wert zurückliefern, liegt an dem Java Interface, an das wir uns gehalten haben. Diese Methoden geben true zurück. sobald sich die Collection durch Aufruf die Collection verändert hat. retainAll erzeugt den Schnitt zweier Mengen. Neben den hier Aufgeführten Klassen gibt es noch drei Exceptions, die wir eingeführt haben.

Wie wir das ganze dann tatsächlich implementiert haben, zeige ich euch morgen.

Jetzt geht’s aber los mit der Übersicht über die Lösungen und meinen Kommentaren dazu:

• Sebastian vom Milchtüten Blog
  Ich fange einfach mal mit der Lösung von Sebastian an, weil ich ihn am besten kenne und somit viel besser auf die Fehler eingehen kann, ohne einen Mordanschlag zu befürchten. Gut finde ich hier natürlich, dass er sich an eine bereits existierende Klasse der SPL hält: dem ArrayIterator. Dadurch wird das ganze schön schlank und natürlich auch Fehler unanfälliger. Es gefällt mir auch, dass die Klasse, die das Set halten soll, über den Konstruktor definiert wird. Wo auf jeden Fall ein Problem bei Sebastians Lösung besteht ist der “falsche” Umgang der Klassenhierachien. Sobald ich eine Klasse B von Klasse A ableite, so ist die Klasse B auch vom Typ A und halt auch vom Typ B, denn nach außen bietet B alles, das auch A bietet und kann somit gleich behandelt werden. Aus diesem Grund sollte man auch mit der is_a Relation arbeiten und nicht über get_class und dann “==”, da man hier die Hierarchien nicht beachtet.
  Leider ist es auch nicht sehr performant, bei jedem hinzufügen alle bereits hinzugefügten Elemente durchzuiterieren, um zu prüfen, ob bereits im Set vorhanden ist. O(n) ist eher eine schlechte Komplexität, zu Zeiten von Hashtables O(1).
• unset von PHP Hacker
  Bei unset findet man viele der soeben besprochenen Ansätze von Sebastian wieder, auch er hält sich an die SPL und auch er verwendet “==” beim Vergleichen der Klassen. Eine Kleinigkeit noch, für die ich wohl einen Klugscheisserpunkt verdient haben werde, denn in einem Prototypen ist dies egal. Und zwar sollte man nie Standard Ausnahmen verwenden. Ich tippe mal drauf, dass beide im Produktivcode eine expliziete Exception genommen hätten, ich wollte es aber trotzdem loswerden.
  Was ich beim phphacker noch schön finde, ist, dass er Methoden verwendet, wenn dies möglich ist. Warum aber getType eine öffentliche Methode ist, weiß ich nicht. Ich kann mir eigentlich keinen Anwendungsfall vorstellen, in dem diese Methode verwendet werden kann.
  Unset ist leider nicht drauf eingegangen, dass ein Element höchsten einmal im Set sein darf.
• Schwobeseggl
  Der erste der sich an das Set herangetraut hat ohne die SPL um Hilfe zu bitte. Muss ja nicht schlecht sein. Wobei ich Matthias doch raten würde ein wenig mehr auf private Methoden zu setzen, denn es macht es dem Leser einfacher durch den Code durchzusteigen. Aber wieder zurück, der Schwobeseggl hat sich dazu entschieden das ganze als Stapelspeicher zu implementieren, was natürlich allen gestellten Anforderungen entspricht. Anders als die anderen übergibt er den “Typ” des Sets nicht im Konstruktor, sondern im macht es am ersten Element fest, das dem Set hinzugefügt wird. Ich bevorzuge, die Konstruktor Lösung, da ich zu einem späteren Zeitpunkt nie weiß, welches das erste Element ist. Wenn dieses schon verkehrt ist, so kann ich mir nicht sicher sein, warum ein Fehler auftritt, bzw. welches der Elemente falsch war.
  Die Reflection API zu bemühen ist natürlich auch eine nette Idee, aber in unserem Fall hätte auch ein get_class gereicht. Ich denke, dass es über get_class weniger kostet und außerdem ist es nur ein Befehl statt mehrerer. Auch befinden wir uns wieder in O(n) in unserer Komplexität.
  Auch von der Verwendung von gettype( ) rät php.net ab, wenn man es dazu verwendet um auf einen bestimmten Typ zu prüfen, da sich die Zeichenkette in späteren Versionen von PHP ändern kann. Ich finde die Lösung vom Schwobeseggl aber auf keinen Fall schlecht, sie macht das was es machen soll.
• Schaelle
  Auch hier wunderbar gemacht. Einfach an die SPL gehalten und alles Methoden schön kommentiert. Leider kann man hier nur primitive Typen, wie String oder Bool reinpacken. Spannender wird es natürlich bei Objekten. Martin arbeitet bei der Prüfung, ob ein Element im Set enthalten ist aber auch über ein foreach, was wieder zu O(n). Ich mags aber, dass Schaelle klar nach dem Motto “Separation of Concerns” arbeitet und ein neues Objekt zur Verfügung stellt, dass ein Set Element representiert.
  Die Liste mit den ganzen is_bool( ) || is_string( )... hätte er wohl ein wenig einfacher hinbekommen können über ein !( is_array( ) || is_object( ) ).  Leider verstehe ich nicht, warum er sein Set nur auf primitive Typen beschränkt hat, denn soweit ich das erkennen kann hängt es nur am Hashwert für ein Objekt. Und dafür bringt ja PHP schon Hausmittel mit.
  Leider finde ich auch nicht die Stelle, wo er prüft, ob die Typsicherheit gegeben ist, aber ansonsten auf jeden Fall eine nette Lösung.
• Andy G.
  Andy hat mir seine Lösung per E-Mail zugeschickt. Nett hierbei finde ich, dass Andy alle Grundfunktionalität in eine abstrakte Klasse gepackt hat und dann diverse Klassen abgeleitet. Da schlägt doch das OOP Herz höher. Leider gibt es auch hier keine Implementierung, die es ermöglicht Objekte zur Menge hinzufügen. Die compareTwoValues Methoden sind meiner Meinung nach alle ein wenig umständlich gelöst. Ein return $value1 === $value2; hätte z.B. im intSet völlig ausgereicht.
  Ansonsten denke ich, dass auch die Lösung von Andy nicht schlecht ist, nur fände ich es besser, wenn er die ganzen casts weglassen und dafür exceptions werfen würde.

So das waren auch schon die fünf Lösungen, die bei mir eingegangen sind. Von Axel, der eine PHP Erweiterung schreiben wollte, habe ich bereits die Absage bekommen, dass er leider keine Zeit finden wird. Auch Lars Jankowfsky tut es Leid.
Ich würde mich übrigens sehr freuen, wenn ihr euch auch die diversen Lösungen mal anschaut und mir eure Meinung dazu sagt. Ansonsten würde ich sagen stelle ich morgen einfach die Lösung von Timo und mir vor.

Ich hoffe, dass hier auch Anfänger mitmachen, denn ich denke, dass man in der Lösungsrunde Tipps für seinen Ansatz bekommen und sich vielleicht ein paar Ideen von den „Profis“ abschauen kann.

Hier also die erste Aufgabe:
Wir benötigen ein typsicheres Set. Ein Set ist eine Menge, in der jedes Element höchstens ein Mal vorkommen kann.

Eigentlich will ich die Aufgabe gar nicht genauer definieren, weil sonst der kreative Spielraum minimiert wird und ich dies nicht vorhabe. Wenn ihr aber Fragen habt, dann könnt ihr die natürlich stellen.

Also ihr Timos, Ralfs, Axels, Damians, Gerds, Franks, Sebastians, Adrians, Max’, Caros, Steffies, Jans, Peters, Chipmunks, Ewes, Björns, Johannes’, Stefans, Lars, kbs, … die ihr hier alle mitlest, nehmt euch die 15 Minuten Zeit, ich zähle auf euch.