"5 Strengths of PHP"

[Sven Rautenberg]

Moin!

In Kombination mit Dereferencing, können wir Method-Chaining benutzten. Stell dir eine Liste von Produkten vor, wir wollen den Gesamtpreis ermitteln:

gesamt = produkte.map( getPreis ).reduce( sum );

In prozeduraler Schreibweise sähe das so aus:

gesamt = reduce( map( produkte, getPreis ), sum );

Es gibt einen einfacheren Weg:

gesamt = produkte.gesamtpreis();

Du wirst aber keine Klasse haben, "produkte" heißt oder? ;)

'...haben, DIE "produkte" heißt, oder?'

"produkte" ist im Sinnzusammenhang der Variablenname, nicht der Klassenname.

Warenkorb.gesamtpreis() könnte ich mir noch vorstellen, aber das ist semantisch dann auch etwas anderes. Denn nicht immer stellt eine Liste an Produkten einen Warenkorb dar.

Richtig, aber genau das ist mein Kernpunkt: Wenn man darüber redet, in welchem Sinnzusammenhang eine Ansammlung von mehreren Produkten zu sehen ist, und was man damit so alles machen kann, dann ist genau das das Argument gegen generische Collections ohne sinnvolle Methoden, die eben genau diesen Sinnzusammenhang widerspiegeln.

Listen von Produkten - das könnte in einem Shop ein Warenkorb sein. In diesem Sinnzusammenhang kann ein Produkt ein oder mehrere Male im Warenkorb liegen, wird einen Preis haben und es wird sinnvoll sein, den Warenkorb nach seinem Gesamtpreis zu fragen.

Listen von Produkten - das könnte auch einfach eine Teilmenge der Produkte in einer bestimmten Shop-Kategorie sein, die man sich anzeigen lassen will. In diesem Zusammenhang ist ein Gesamtpreis absolut sinnlos, ebenso eine Anzahl. Allerdings wird man wohl besonderen Einfluss auf die Reihenfolge nehmen wollen, denn Produkte in solchen Listenansichten lassen sich gerne nach diversen Kriterien sortieren, z.B. nach Preis, Beliebtheit, Bewertung oder Gewicht.

Listen von Produkten - das wird nach dem Klick auf den Bestellbutton eben kein Warenkorb, sondern eine Order sein, die zwar immer noch Anzahl, Preis und Gesamtpreis umfasst, jetzt aber auch Dinge wie Inventar, Lieferstatus, Retouren etc. - das aber individuell pro Produkt. Die Order selbst dürfte hingegen noch Dinge wie Zahlungsstatus, Lieferstatus etc. enthalten.

Natürlich kann man alle drei Listen von Produkten mit ein-und-derselben Collection realisieren, die einfach nur anbietet, mit Map-Reduce die passenden Funktionen auf diese Liste zu werfen, um jeweils unterschiedliche Ergebnisse zu erzielen. In einfachen Software-Konstruktionen dürfte das vermutlich auch ein schneller Weg sein. In komplexer Business-Software funktioniert das eher nicht. Da muss man sich nicht nur Gedanken machen, was ein Produkt überhaupt ist, und was das Besondere an seiner Listenform ist. Man muss sich auch Gedanken machen, wie die einzelnen Listen ineinander zu überführen sind.

Wie wird aus einer angezeigten Produktliste ein Warenkorb? Wie wird aus einem Warenkorb eine Order? Beide Schritte machen mit der Liste von Produkten irgendetwas - und was genau, das ist vermutlich der Kern der Businesslogik, um die sich die Applikation dreht.

Insofern ist es absolut gerechtfertigt, wenn man für Businesslogik Klassen entwirft, die diese Logik in Code umsetzen, und deshalb sachgerechte Methoden anbieten, um diese Transformationen unmißverständlich umzusetzen. Beispielsweise durch $order = $customer->orders($basket);. Mit einem Kundenobject $customer, einem Warenkorbobjekt $basket und einem Orderobjekt $order (letztere enthalten jeweils eine Liste von Produkten).

Das Argument spielt sich augenscheinlich ausschließlich auf Datenstrukturebene ab. Natürlich sind Datenstrukturen nicht überflüssig oder irrelevant, aber nach meiner Wahrnehmung ist der relevantere Teil die einer Applikation innewohnende Businesslogik.

...und diese ist fest mit den Datenstrukturen gekoppelt. Denn Datenstrukturen sollen ja Dinge aus der realen Welt abstrakt repräsentieren - sonst bräuchten wir sie nicht. Und Dinge, die in der realen Welt sehr oft vorkommen, werden eben als gängige Datenstrukturen von der Sprache bereitgestellt, sodass sie nicht mehr selbst gebastelt werden müssen. Dazu gehören Listen, Maps und anderes.

Nein, ich glaube eher nicht, dass die Businesslogik FEST mit Datenstrukturen gekoppelt ist. Tatsächlich würde ich eher glauben, dass die Businesslogik sehr fest strukturiert ist, die zugehörigen Daten aber tatsächlich einem relativ starken Wandel unterliegen können.

Beispiel: SEPA. Die konkreten Kontoverbindungsdaten haben sich ziemlich massiv geändert. Die drumherumliegende Logik einer Kontoverbindung auch. Auf höherer Ebene hingegen hat sich eigentlich nichts getan: Eine Kundenbestellung mit Zahlungsart "Abbuchung" braucht eine gültige Kontoverbindung.

Ein PHP-Array kann alles sein, ein Dictonary, eine Menge, ein Tupel, ein Stapel eine Schlange. Es erklärt sich mir nicht von selbst, welche Methoden überhaupt Sinn darauf machen.

Man wird sicherlich Arrays eher intern innerhalb von Objekten verwenden, um irgendein konkretes der obigen Konzepte abzubilden, und sie nicht nach außen anbieten. Auf der anderen Seite spricht aus meiner Sicht nichts dagegen, Arrays genau dann einzusetzen, wenn "mehr als eins" in einer Datenstruktur vorkommt - auch öffentlich erreichbar.

Wenn man das tut, dann ist es auch okay. Nur leider, muss man sich dann z.B. "normalen" Listen erstmal selbst definieren anstatt arrays dafür benutzen zu können. Trotzdem stimme ich dir in diesem ersten von dir genannten Punkt zu.

Wie ich oben ausführte, will man das sogar, weil auch Listen Logiken implementieren. PHP bietet dafür auch ausreichend Basismaterial an, dass man verwenden könnte: Diverse Interfaces (Countable, Traversable, ArrayAccess) und Objekte (ArrayIterator, ArrayObject, SplFixedArray, SplObjectStorage, SplDoublyLinkedList).

Es gilt allerdings der Satz aus dem Aufhänger-Artikel: Native PHP-Arrays sind so verdammt nützlich, es gibt selten einen Grund, sie nicht zu verwenden.

- Sven Rautenberg