Seite 2 - Design Patterns

Eine Pure Function liefert bei gleichen Argumenten immer dasselbe Ergebnis und verändert nichts außerhalb ihres eigenen Rückgabewerts. Dieses Prinzip der referenziellen Transparenz macht PHP-Code vorhersagbar, leicht testbar und parallelisierbar, ganz ohne zusätzliches Framework oder neue Sprachsyntax.

Ein Upload-Formular mit loading, error, success und retry als vier separate boolesche Flags erzeugt schnell unmögliche Kombinationen. Ein State-Machine-Pattern in Alpine.js ersetzt diese Flags durch einen einzigen, benannten Zustand mit klar definierten Übergängen und macht komplexe UI-Zustände dadurch vorhersagbar und wartbar.

Die meisten Erklärungen zu SOLID-Prinzipien arbeiten mit Formen, Enten oder Tieren und lassen offen, wie das in echtem Anwendungscode aussieht. Dieser Artikel nimmt stattdessen eine durchgehende Order-Processing-Pipeline in PHP 8.4, an der jedes der fünf Prinzipien ein konkretes, nachvollziehbares Wartbarkeitsproblem löst: eine Order-Klasse, die zu viel macht, Rabattregeln, die zu einer if/else-Kaskade wuchern, ein Payment-Gateway, das seinen eigenen Vertrag bricht, ein zu fettes Repository-Interface und ein Notification-Service, der zu eng an einen konkreten Mailer gekoppelt ist.

Ein watch() auf ein flaches Property funktioniert in Alpine.js sofort zuverlässig. Sobald ein verschachteltes Objekt oder ein Array von Objekten beobachtet werden soll, tauchen Überraschungen auf: Änderungen werden übersehen, Callbacks feuern zu selten oder zu oft. Dieser Artikel zeigt, wie Deep-Watching in Alpine.js tatsächlich funktioniert und mit welchen Patterns es zuverlässig wird.

Ein Fehler in einer asynchronen Funktion verschwindet spurlos, die Konsole zeigt eine unhandled rejection, ein leerer catch-Block versteckt genau das Problem, das gerade gesucht wird. Promise-Fehlerbehandlung folgt eigenen Regeln, die sich von synchronem try catch unterscheiden. Dieser Artikel zeigt die konkreten Fallstricke und wie man sie zuverlässig vermeidet.

Doctrine oder Eloquent zu benutzen ist einfach, zu verstehen, warum sie so funktionieren, wie sie funktionieren, ist es nicht. Wer einmal ein eigenes minimales ORM gebaut hat, versteht Hydration, Unit of Work und Identity Map nicht mehr abstrakt, sondern als konkrete Entscheidungen mit klaren Kompromissen.

Module Federation lädt Vue-Komponenten erst im Browser aus getrennt deployten Anwendungen nach, statt sie zur Build-Zeit einzubinden. Das ermöglicht unabhängige Deployments über Teamgrenzen hinweg, verlangt aber eine bewusste Strategie für geteilte Abhängigkeiten, Versionskonflikte und Fallbacks, wenn ein Remote nicht erreichbar ist.

Wiederkehrende Prüfungen wie if ($logger !== null) verteilen sich schnell über eine ganze Codebasis und verstecken die eigentliche Businesslogik hinter defensiver Programmierung. Das Null Object Pattern ersetzt fehlende Objekte durch ein neutrales Objekt mit demselben Interface, das sich einfach nichts tuend verhält, statt eine Fallunterscheidung zu erzwingen.

Das Decorator Pattern löst ein Problem, das reine Vererbung nicht sauber lösen kann: mehrere unabhängige Zusatzverhalten, etwa Logging, Caching und Validierung, flexibel und in beliebiger Reihenfolge kombinieren, ohne für jede Kombination eine eigene Unterklasse zu bauen. Dieser Artikel zeigt, wie das Decorator Pattern in PHP Interface-Konformität wahrt und wann es dem Aufblähen von Vererbungshierarchien vorzuziehen ist.

Signals sind ein Reaktivitäts-Muster, das in Vue, Solid, Preact und Angular unabhängig voneinander implementiert wurde, aber auf denselben wenigen Grundbausteinen beruht. Wer versteht, wie ein minimales Signals-System aus Getter, Setter und automatischem Dependency-Tracking aufgebaut ist, kann Reaktivität in jedem Vanilla-JavaScript-Projekt einsetzen, ganz ohne Framework-Abhängigkeit.