Du als API Entwickler hast es nicht immer einfach. Du möchtest es anderen Entwicklern aber natürlich recht einfach machen und als Sahnehäubchen soll das Ganze auch noch wenig fehleranfällig sein.
Gehen wir einmal davon aus, du hast dein erstes Modul für QUIQQER geschrieben. Dein Modul bietet nun eine Schnittstelle an, in dem andere Entwickler über verschiedene Klassen dein Modul erweitern können.
Damit das ganze Hand und Fuss hat bietest du ein Interface an. Dein Interface legt alle Schnittstellen und Methoden fest, von denen du ausgehst.
Damit du auf alle Erweiterungen von anderen Modulen zugreifen kannst, sammelst du diese in einem Array.
Wie kannst du nun sicher gehen, dass auch wirklich nur Objekte in deinem Array landen und dann auch Objekte welche noch von deinem Interface erben?
Für solche Fälle bieten sich in QUIQQER sogenannten Collections an. Einige sollten Collections kennen, einige vielleicht nicht und können mit Collections noch nicht soviel anfangen. Eine Collection ist in der Programmierung meist ein Objekt, welches ein Array nachahmt. Man kann sich das vorstellen wie ein Array mit Superpower.
Die Superpower kommt daher, da das Objekt alle Methoden beinhaltet um die darin enthaltenen Daten zu manipulieren.
Wenn wir das jetzt mit einem Array machen wollen - das Array zum Beispiel filtern, durcheinander würfeln oder splitten - haben wir meist eine weitere Variable oder zerstören unser Quell-Array. Soweit ist das alles nicht schlimm, jedoch ist es nicht gerade hilfreich für die Lesbarkeit.
Zusätzlich gibt es ein Problem: in ein Array kann jeder einfügen, was er will. Ich habe keine Möglichkeit zu verhindern, dass jemand Int Werte, Bool Werte oder Objekte rein stopft.
Für API Anbieter ist das etwas doof. Oft hat man den Fall, dass eine Array-Liste existiert, die andere Entwickler erweitern können / sollen. Zum Beispiel nehmen wir in QUIQQER sogenannte Provider. Das sind Klassen, welche Funktionalität für einen bestimmten Zweck von einem bestimmten Plugin bereitstellen.
Ein gutes Beispiel für einen Provider wäre ein ERP-Provider. Das ERP-Modul liest alle Plugins aus und schaut ob diese Plugins ERP-Provider zur Verfügung stellen. Wenn ja, nimmt es diese auf.
Als API Anbieter möchtest du nun, dass die ERP-Provider Klasse von einer bestimmten Klasse abhängig ist. Wenn der ERP-Provider nicht von der Klasse abhängig ist, soll dieser erst gar nicht aufgenommen werden.
Das nächste Beispiel verdeutlicht einmal das Problem.
Provider werden generell über die package.xml in QUIQQER registriert.
Zum Beispiel:
Die Klasse QUI\ERP\Order\ErpProvider muss von der Klasse QUI\ERP\Api\AbstractErpProvider erben. Was passiert aber, wenn das der Modul Entwickler vergisst? Somit ist nicht gewährleistet, dass der zur Verfügung gestellte ERP-Provider sich wie ein ERP-Provider verhält.
Genau hier kommen die Collections von QUIQQER ins Spiel und auch genau in diesem Punkt unterscheiden sich die QUIQQER Collections von dem standard Collection Konzept. Um das Problem mit dem ERP-Provider zu lösen, gibt es mehrere Möglichkeiten.
- An jeder Stelle an der du die ERP-Provider benötigst, gehst du alle ERP Provider durch und prüfst immer, ob die Objekte alle von der QUI\ERP\Api\AbstractErpProvider erben.
Nun das ist etwas mühselig und umständlich und manchmal vergisst man die Prüfung - also auch sehr fehleranfällig.
- Du nutzt eine QUI\Collection und bietest dieses als eine Art Sammelobjekt an, welches alle ERP-Provider auf nimmt. Das schöne an einer QUI\Collection ist es, dass bestimmt werden kann, welche Art von Kind-Elementen (Objekte) in die Collection dürfen.
Die grundlegende Vorgehensweise bei Collections ist einfach.
Du brauchst eine Art Sammel-Objekt welches von der QUI\Collection erbt
Mit diesem Sammelobjekt arbeitest du dann
Das ist alles. Wenn du nun eine Instanz von der MyProvider Klasse aufbaust, ist das eine Collection, welche nur QUI\ERP\Api\AbstractErpProvider in sich aufnimmt.
Collections anwenden
Ich zeige einmal wie die MyProvider Collection verwendet werden kann.
Wie man sieht ist das ganze durch die Collections recht einfach geworden.
Ich hoffe, dem einen oder anderen API Entwickler wird die QUI Collection helfen. Dadurch wird deine API auf jeden Fall einfacher und auch sicherer (stabiler) in der Anwendung.