discussion PHP8 Feautures

[Igäl]

Liebe Gemeinde

Wie gesagt fliesst meine Freizeit wieder stark in mein Hobbyprojekt. Es ist eine abgespeckte Rule Engine für Dungeons & Dragons 2024. Abgespeckt deswegen, weil ich mit meiner Gruppe weiterhin am Tisch würfle und weiterhin am Tisch Schaden berechne und manuell abziehe. Also eher ein Charakterbogen+ und ein Management Tool für Zustände, Inventar, Gear etc.

Mein altes Framework basierte noch auf PHP 4 und 5 und wurde punktuell erweitert. Grossmehrheitlich ist es aber Spaghetticode im OOP-Pelz. Entsprechend ist das Refactoring mit allem was PHP 8+ zu bieten hat ein riesen Schritt und eigentlich eine neue Programmiersprache, die ich mir aneignen muss.

Aus diesem Grund bin ich interessiert an Austausch. Und auch, weil wir ja jetzt diese Forum wieder etwas mit Inhalt füllen wollen, richtig? Entsprechend möchte ich wissen, wie eure Erfahrungen mit gewissen Feautures sind und ob ihr sie in Gebrauch habt. Falls ja, warum, falls nein, warum nicht?

Unlängst bin ich auf zwei Themen gestossen, die meine Architektur vermutlich prägen werden, sofern sich deren Einsatz bewährt. Die Rede ist von asymmetric visibility (für Entities) und Wither-Methoden (für DTOs) .

Architektonisch habe ich mich dazu entschieden, dass meine Repositories jeweils Entitys oder Config-Container befüllen. In einem Domain Driven Design im Backend und einem Data Driven Design in der Datenbank kommen da ziemlich viele solcher Klassen zusammen. Entsprechend schreibt man sich mit getter- und setter-Methoden die Finger wund. Genau für diesen Fall habe ich die asymmetric visibility entdeckt.

class someEntity {
    public function __construct(
        public private(set) int $someId,
        public private(set) string $someTitle,
        public private(set) array $someAttributes
    ) {}
}

Das eliminiert mir auf einen Schlag drei Getter-Methoden und ich muss nur noch die Setter schreiben.

In diesem Zusammenhang nimmt mich wunder, ob ihr das ähnlich macht oder ob ihr eure Variablen mit public mutable belässt oder gar auf private setzt und getter-Methoden einfügt. Auch auf das Warum bin ich neugierig, weil ich in PHP8 noch wenig Erfahrung habe und eventuell auch gewisse Fallstricke übersehe.

Das andere sind meine DTOs, an welche ich den Anspruch habe, dass sie die Datenintegrität 100%ig gewährleisten. Diese werden, wo vorhanden, aus den Config-Containern generiert. Das ist kein Problem, wenn ein DTO mit den finalen Daten instanziert werden kann, wird aber zum Problem, wenn es nachträgliche Änderungen im DTO gibt.

class someDTO    {
    public function __construct(
        public readonly int $someId,
        public readonly string $someTitle,
        public readonly array $someAttributes
    ) {}
}

Man denke beispielsweise an eine Edit-Funktion für News, wo der Controller das Formular für die Anzeige rendert, aber noch keine Daten hat, um die value-Attribute der Form-Felder zu füttern. Meine Herangehensweise ist, dass ich das DTO für das Frontend einfach ersetze, indem ich eine Wither-Methode im DTO aufrufe, die quasi bewirkt, dass sich das DTO als Kopie neu aufsetzt, jedoch einzelne Parameter mit geänderten Werten instanziert.

Das erhält mir die Datenintegrität, jedoch finde ich es etwas unschön, dass ich in derselben Methode (bspw. einer Funktion in einem Controller) ein DTO erstelle, Daten modifiziere und dann gleich nochmals ein DTO erstelle, das die Daten des zuvor erstellten DTOs überschreibt. Aber ich sehe keine Alternative, wenn ich fully protected DTOs bereitstellen möchte.

Was sind eure Erfahrungen, respektive Lösungsansätze mit diesem Pattern?

Kennt ihr irgendwelche Gamechanger aus PHP8 (oder auch 6 und 7 🙂)? Aktuell bin ich dankbar für alles, was mir meinen alten Spaghetticode sinnvoll entflechten hilft.

So long,

dä Igäl.

 

[kai_web]

Bin eher Webseiten-Bastler als Backend-Architekt, aber für reine DTOs würde ich readonly-Klassen nehmen, dann brauchst du da gar kein private(set). Und mit clone() samt Property-Array in PHP 8.5 werden Wither ziemlich kurz. private(set) finde ich vor allem bei den Entities spannend, wo sich intern doch noch was ändern soll.