Property Hooks in PHP 8.4: Getter/Setter ohne Boilerplate

1. Das Boilerplate-Problem klassischer Getter/Setter

In praktisch jeder objektorientierten PHP-Codebasis findet sich dasselbe Muster: eine private Property, dazu eine öffentliche getName()-Methode, die den Wert unverändert zurückgibt, und eine setName()-Methode, die eine Validierung durchführt, bevor sie den Wert zuweist. Für eine Klasse mit zehn Eigenschaften bedeutet das schnell zwanzig zusätzliche Methoden, von denen die meisten nichts weiter tun, als eine Zeile Code auszuführen. Dieser Boilerplate-Code ist nicht falsch, aber er verdeckt die eigentliche Geschäftslogik hinter viel Zeremonie, die bei jeder neuen Property erneut geschrieben werden muss.

Das eigentliche Problem ist nicht die Tipparbeit, sondern die Wartbarkeit. Wenn eine Validierungsregel sich ändert, muss sie in der Setter-Methode angepasst werden, und Entwickler müssen wissen, dass diese Methode existiert, statt die Property direkt zu setzen. In vielen Projekten wird diese Disziplin nicht konsequent durchgehalten: Irgendwo im Code greift eine Legacy-Methode direkt auf eine public Property zu und umgeht damit jede Validierung, weil PHP vor Version 8.4 keine Möglichkeit bot, Lese- und Schreibzugriff auf eine Property selbst mit Verhalten zu belegen, ohne sie komplett hinter Methoden zu verstecken.

Property Hooks lösen genau dieses Spannungsfeld. Statt eine Property zu verstecken und über Methoden zugänglich zu machen, bleibt die Property als solche sichtbar und wird trotzdem mit Verhalten versehen. Der Zugriff $user->email = 'foo@bar.de' sieht syntaktisch aus wie eine einfache Zuweisung, kann aber im Hintergrund validieren, normalisieren oder sogar komplett berechnen, ohne dass der Aufrufer davon etwas mitbekommt oder eine Methode aufrufen muss. Das reduziert nicht nur die Zeilenzahl, sondern beseitigt die Versuchung, eine Property versehentlich ungeprüft zu setzen, weil es schlicht keinen ungeprüften Zugriffspfad mehr gibt.

2. Syntax von Property Hooks: get und set

Die Grundsyntax von Property Hooks fügt der Property-Deklaration einen Block in geschweiften Klammern hinzu, der einen get-Hook und einen set-Hook enthalten kann. In der Kurzform mit Pfeilfunktion sieht das so aus: public string $name { get => strtoupper($this->name); }. Der Ausdruck nach => wird bei jedem Lesezugriff auf die Property ausgewertet. Für komplexere Logik gibt es die Blockform mit geschweiften Klammern und einem expliziten return-Statement, in der beliebig viele Anweisungen stehen dürfen, bevor der Wert zurückgegeben wird.

Der set-Hook funktioniert spiegelbildlich: Er nimmt einen impliziten Parameter namens value entgegen, der den zugewiesenen Wert repräsentiert, und kann diesen vor der eigentlichen Speicherung prüfen oder transformieren. Wichtig ist, dass innerhalb eines Hooks der Zugriff auf $this->propertyName auf das sogenannte Backing-Field verweist, also den tatsächlich gespeicherten Wert, nicht rekursiv auf den Hook selbst. PHP erkennt diesen Unterschied automatisch anhand des Kontexts, sodass get => $this->name ohne zusätzliche Konvention funktioniert, ohne eine Endlosschleife auszulösen.

Eine Property kann auch nur einen der beiden Hooks definieren. Eine Property mit ausschließlich einem get-Hook verhält sich effektiv wie eine berechnete, nur lesbare Eigenschaft. Eine Property mit ausschließlich einem set-Hook behält ihr normales Leseverhalten, validiert aber jede Zuweisung. Diese Flexibilität erlaubt es, für jede einzelne Property genau die Kontrolle zu implementieren, die tatsächlich gebraucht wird, statt pauschal beide Richtungen abzudecken.

declare(strict_types=1);

final class Product
{
    public function __construct(
        private string $name,
        private float $priceNet,
    ) {
    }

    // Short-form get hook: normalizes on every read access
    public string $name {
        get => trim($this->name);
    }

    // Block-form set hook: validates and normalizes before storing
    public float $priceNet {
        set {
            if ($value < 0.0) {
                throw new InvalidArgumentException('Price must not be negative.');
            }
            $this->priceNet = round($value, 2);
        }
    }
}

$product = new Product('  Keyboard  ', 49.995);
echo $product->name;      // "Keyboard" - trimmed by the get hook
echo $product->priceNet;  // 50.0 - rounded by the set hook

3. Virtuelle Properties ohne Backing-Field

Ein besonders nützlicher Anwendungsfall von Property Hooks sind virtuelle Properties, also Eigenschaften, die überhaupt keinen eigenen gespeicherten Wert besitzen. Sobald eine Property nur einen get-Hook definiert und in diesem Hook nicht auf ein Backing-Field verweist, sondern den Wert vollständig aus anderen Properties berechnet, existiert kein Speicherplatz für diese Property im Objekt. PHP legt in diesem Fall kein Backing-Field an, was Speicher spart und gleichzeitig ausschließt, dass ein veralteter, zwischengespeicherter Wert zurückgegeben wird.

Ein typisches Beispiel ist eine Property fullName, die aus firstName und lastName zusammengesetzt wird. Statt eine eigene Instanzvariable zu pflegen, die bei jeder Änderung von Vor- oder Nachname synchron gehalten werden müsste, berechnet der get-Hook den Wert bei jedem Zugriff neu. Das eliminiert eine ganze Klasse von Synchronisationsfehlern, bei denen eine abgeleitete Property nach einer Änderung an den Quell-Properties vergessen wird zu aktualisieren.

Virtuelle Properties eignen sich auch für Werte, die aus externen Quellen abgeleitet werden, etwa ein Formatierungs- oder Anzeigewert, der auf Basis eines internen Rohwerts berechnet wird. Wichtig ist dabei die Unterscheidung: Eine virtuelle Property mit reinem get-Hook ist grundsätzlich nur lesbar. Wird versucht, ihr einen Wert zuzuweisen, wirft PHP einen Fehler, da kein set-Hook und kein Backing-Field existieren, in das geschrieben werden könnte. Diese Klarheit ist ein Vorteil gegenüber klassischen Gettern, bei denen die fehlende Schreibmöglichkeit nicht aus der Signatur ersichtlich ist, sondern nur aus der Abwesenheit einer Setter-Methode.

declare(strict_types=1);

final class Customer
{
    public function __construct(
        private string $firstName,
        private string $lastName,
    ) {
    }

    // Virtual property: no backing field, computed on every access
    public string $fullName {
        get => sprintf('%s %s', $this->firstName, $this->lastName);
    }

    // Virtual, derived, read-only presentation value
    public string $initials {
        get => strtoupper($this->firstName[0] . $this->lastName[0]);
    }
}

$customer = new Customer('Ada', 'Lovelace');
echo $customer->fullName;  // "Ada Lovelace" - computed, never stored
echo $customer->initials; // "AL"

// $customer->fullName = 'New Name'; // Error: no set hook defined

4. Validierung und Transformation im set-Hook

Der wohl häufigste Anwendungsfall für Property Hooks in der Praxis ist die Validierung von Eingabedaten direkt bei der Zuweisung. Statt eine private Property zu deklarieren und eine separate setEmail()-Methode zu schreiben, die die Validierung übernimmt, wird die Prüfung direkt in den set-Hook der Property verlagert. Jede Zuweisung, egal ob im Konstruktor über Constructor Property Promotion oder später im Code, durchläuft automatisch dieselbe Validierungslogik, ohne dass ein Entwickler daran denken muss, die richtige Methode statt einer direkten Zuweisung zu verwenden.

Neben reiner Validierung, die bei einem ungültigen Wert eine Exception wirft, eignet sich der set-Hook ebenso für Normalisierung. Ein Telefonnummern-Feld kann beim Setzen automatisch Leerzeichen und Bindestriche entfernen, ein E-Mail-Feld kann in Kleinbuchstaben umgewandelt werden, bevor der Wert im Backing-Field landet. Diese Transformation passiert transparent für den Aufrufer: Er weist einen Rohwert zu und liest später den normalisierten Wert zurück, ohne einen zusätzlichen Aufruf einer Normalisierungsfunktion einzubauen.

Ein wichtiges Detail ist die Möglichkeit, den Typ des impliziten value-Parameters im set-Hook enger oder anders zu deklarieren als den deklarierten Typ der Property selbst, etwa um zusätzlich zu einem string auch Stringable-Objekte zu akzeptieren und im Hook auf einen reinen String zu normalisieren. Das erlaubt eine großzügigere, entwicklerfreundliche API nach außen, während intern immer nur der strikt typisierte, geprüfte Wert gespeichert wird. Diese Kombination aus Toleranz beim Input und Strenge beim gespeicherten Zustand war mit klassischen Property-Deklarationen ohne zusätzliche Setter-Methode schlicht nicht abbildbar.

declare(strict_types=1);

final class EmailAddress
{
    public string $value {
        set {
            $normalized = strtolower(trim($value));
            if (!filter_var($normalized, FILTER_VALIDATE_EMAIL)) {
                throw new InvalidArgumentException(
                    sprintf('"%s" is not a valid email address.', $value)
                );
            }
            $this->value = $normalized;
        }
    }

    public function __construct(string $value)
    {
        $this->value = $value; // Runs through the set hook above
    }
}

$email = new EmailAddress('  User@Example.COM  ');
echo $email->value; // "user@example.com" - validated and normalized

5. Berechnete Werte im get-Hook

Während virtuelle Properties komplett ohne Backing-Field auskommen, gibt es einen zweiten, ebenso häufigen Fall: eine Property besitzt ein Backing-Field, aber der get-Hook wandelt den gespeicherten Rohwert bei jedem Lesezugriff um. Ein Beispiel ist ein interner Betrag in Cent, der beim Lesen als formatierter Euro-Betrag mit zwei Nachkommastellen ausgegeben wird, während intern weiterhin mit Integer-Cent-Werten gerechnet wird, um Rundungsfehler bei Fließkommazahlen zu vermeiden.

Eine wichtige Falle bei berechneten get-Hooks betrifft Performance und Caching. Da der Hook bei jedem einzelnen Lesezugriff ausgeführt wird, ist eine teure Berechnung, etwa eine aufwendige String-Verarbeitung oder gar ein Datenbankzugriff, in einer Schleife mit vielen Lesezugriffen entsprechend teuer. Property Hooks bieten dafür kein eingebautes Memoization, das Ergebnis wird nicht automatisch zwischengespeichert. Wer das Ergebnis cachen möchte, muss dies explizit selbst umsetzen, etwa mit einer zusätzlichen nullable Property, die beim ersten Zugriff befüllt wird.

Ein zweiter Punkt, der leicht übersehen wird: Ein get-Hook, der von anderen, veränderlichen Properties abhängt, muss diese Abhängigkeit bei jeder Auswertung neu berücksichtigen. Ändert sich eine der Quell-Properties zwischen zwei Lesezugriffen, liefert der get-Hook beim zweiten Zugriff automatisch den aktuellen, neu berechneten Wert. Das ist in den meisten Fällen exakt das gewünschte Verhalten, kann aber überraschen, wenn ein Entwickler unbewusst von einem einmalig berechneten, unveränderlichen Wert ausgeht, obwohl die Property bei jedem Zugriff neu ausgewertet wird. Ein typisches Beispiel ist ein interner Cent-Betrag mit einem formattedTotal-Hook, der bei jedem Lesezugriff neu formatiert wird: Ohne manuelles Caching über eine zusätzliche private Property wird number_format() bei häufigen Lesezugriffen unnötig oft ausgeführt, was in Rendering-Schleifen mit vielen Listeneinträgen spürbar werden kann.

6. Property Hooks in Interfaces und abstrakten Klassen

Property Hooks lassen sich nicht nur in konkreten Klassen einsetzen, sondern auch als Vertrag in Interfaces deklarieren. Ein Interface kann eine Property mit { get; } ohne Implementierung fordern und damit sicherstellen, dass jede implementierende Klasse eine lesbare Property mit diesem Namen und Typ bereitstellt, unabhängig davon, ob die konkrete Klasse einen echten Hook implementiert oder eine einfache, ungehookte Property verwendet, die denselben Vertrag automatisch erfüllt.

Das ist ein bedeutender Unterschied zu klassischen Gettern in Interfaces: Statt public function getName(): string; zu fordern, deklariert das Interface direkt public string $name { get; }. Für den Aufrufer ändert sich der Zugriff spürbar: Er liest $object->name statt $object->getName() aufzurufen, was insbesondere in Kombination mit Wertobjekten und Datentransferobjekten zu deutlich lesbarerem Code führt, ohne die Garantien eines Interfaces zu verlieren.

In abstrakten Klassen lässt sich dieses Prinzip erweitern: Eine abstrakte Klasse kann einen abstrakten get-Hook deklarieren, den konkrete Unterklassen implementieren müssen, während sie selbst bereits einen konkreten set-Hook mit gemeinsamer Validierungslogik für alle Unterklassen bereitstellt. Diese Aufteilung erlaubt es, gemeinsames Verhalten einmal zu zentralisieren und gleichzeitig spezifisches Verhalten pro Unterklasse zu erzwingen, ganz ähnlich wie bei abstrakten Methoden, nur eben auf Ebene einzelner Properties statt ganzer Methoden.

declare(strict_types=1);

interface HasDisplayLabel
{
    // Contract: any implementing class must expose a readable label
    public string $displayLabel { get; }
}

abstract class AbstractStatus implements HasDisplayLabel
{
    protected string $code = '';

    // Shared validation for all subclasses, enforced through the set hook
    public string $code {
        set {
            if ($value === '') {
                throw new InvalidArgumentException('Status code must not be empty.');
            }
            $this->code = strtoupper($value);
        }
    }

    // Forces every concrete subclass to define its own label computation
    abstract public string $displayLabel { get; }
}

final class OrderStatus extends AbstractStatus
{
    public string $displayLabel {
        get => match ($this->code) {
            'NEW' => 'Neu eingegangen',
            'SHIPPED' => 'Versandt',
            default => 'Unbekannt',
        };
    }
}

7. Vererbung: Hooks überschreiben und erweitern

Beim Vererben von Klassen mit Property Hooks kann eine Unterklasse einen geerbten Hook überschreiben, um zusätzliches Verhalten einzufügen, ohne die Basislogik komplett zu duplizieren. Der Schlüssel dazu ist der Zugriff über parent::$propertyName, mit dem eine Unterklasse gezielt auf das Backing-Field der Elternklasse zugreifen kann, während sie im überschreibenden Hook eigene zusätzliche Prüfungen oder Transformationen ergänzt. Das entspricht konzeptionell dem parent::method()-Aufruf bei überschriebenen Methoden, nur eben angewendet auf Property-Zugriffe.

Bei der Kovarianz gelten für Property Hooks ähnliche Regeln wie für Rückgabetypen von Methoden: Ein überschreibender get-Hook darf einen engeren, spezifischeren Typ zurückgeben als der ursprünglich deklarierte Typ in der Elternklasse, solange dieser Typ mit dem übergeordneten kompatibel bleibt. Für den set-Hook gilt die entgegengesetzte Kontravarianz-Regel: Der akzeptierte Werttyp darf beim Überschreiben nicht enger werden, da sonst der Vertrag der Basisklasse verletzt würde, dass jeder dort gültige Wert auch in der Unterklasse zugewiesen werden kann.

Ein praktisches Beispiel ist eine Basisklasse Money, die im set-Hook lediglich prüft, dass ein Wert nicht negativ ist, während eine Unterklasse ForeignMoney zusätzlich eine Währungsvalidierung ergänzt, aber weiterhin die Basisprüfung über parent::$amount = $value; nutzt, um Codeduplikation zu vermeiden. Diese Kombination aus Wiederverwendung und gezielter Erweiterung war mit klassischen Setter-Methoden zwar über einen Aufruf von parent::setAmount($value) ebenfalls möglich, wirkt bei Property Hooks aber konsistenter, weil sowohl Basis- als auch Unterklasse dieselbe Zugriffssyntax über die Property selbst verwenden.

declare(strict_types=1);

class Money
{
    protected float $amount = 0.0;

    public float $amount {
        set {
            if ($value < 0.0) {
                throw new InvalidArgumentException('Amount must not be negative.');
            }
            $this->amount = $value;
        }
    }
}

final class ForeignMoney extends Money
{
    public function __construct(
        private readonly string $currency,
    ) {
    }

    // Extends the parent hook instead of duplicating the base validation
    public float $amount {
        set {
            if (!in_array($this->currency, ['USD', 'GBP', 'CHF'], true)) {
                throw new InvalidArgumentException('Unsupported currency.');
            }
            parent::$amount = $value; // Reuses the base class validation
        }
    }
}

$payment = new ForeignMoney('USD');
$payment->amount = 42.50; // Runs currency check, then the inherited negativity check

8. Property Hooks vs. klassische Getter/Setter-Methoden

Bei der Performance gibt es keinen praxisrelevanten Unterschied zwischen einem get-Hook und einer klassischen Getter-Methode: Beide werden vom PHP-Engine letztlich als Methodenaufruf mit vergleichbarem Overhead ausgeführt, ein Property Hook ist keine reine Feldzugriff-Optimierung auf Bytecode-Ebene. Der eigentliche Vorteil liegt nicht in der Ausführungsgeschwindigkeit, sondern in der Lesbarkeit des aufrufenden Codes und darin, dass sich Aufrufstellen mit $obj->prop statt $obj->getProp() deutlich kompakter schreiben und in Templates oder Ausdrücken natürlicher lesen lassen.

Bei der Migration bestehender Klassen mit etablierter getX()/setX()-API entsteht eine praktische Kompatibilitätsfrage: Eine bereits veröffentlichte Bibliothek kann nicht einfach ihre öffentlichen Methoden durch Property Hooks ersetzen, ohne die bestehende API zu brechen, da Aufrufer weiterhin ->getName() erwarten. Ein gangbarer Weg ist, die Property Hooks parallel zur bestehenden Methode einzuführen, wobei die Methode intern lediglich die Property liest oder schreibt, sodass neue Aufrufer die kompaktere Property-Syntax nutzen können, während alte Aufrufer unverändert weiterlaufen.

Erwähnenswert ist außerdem die Abgrenzung zu zwei verwandten PHP-8.4-Features: Asymmetric Visibility (public private(set) string $name) regelt, wer eine Property überhaupt schreiben darf, ohne dabei Verhalten wie Validierung einzufügen, und Readonly Properties verhindern jede Änderung nach der Initialisierung komplett. Property Hooks unterscheiden sich davon, weil sie nicht die Sichtbarkeit oder Veränderbarkeit regeln, sondern das tatsächliche Verhalten bei jedem Lese- oder Schreibzugriff bestimmen. Alle drei Features lassen sich in PHP 8.4 kombinieren, adressieren aber unterschiedliche Fragestellungen.

9. Grenzen und Stolperfallen

Eine wichtige Einschränkung von Property Hooks ist, dass ein Hook nicht direkt auf einen anderen Hook derselben oder einer anderen Property zugreifen kann, um dessen Logik wiederzuverwenden. Es gibt keine Syntax, um "den get-Hook einer anderen Property aufzurufen" außer dem regulären Property-Zugriff selbst. Wer Logik zwischen mehreren Hooks teilen möchte, muss diese in eine private Methode auslagern und aus beiden Hooks heraus aufrufen, statt eine direkte Hook-zu-Hook-Referenz zu erwarten, die es in PHP 8.4 schlicht nicht gibt.

Rekursion ist eine reale Gefahr, wenn ein get-Hook versehentlich auf sich selbst statt auf das Backing-Field verweist. Solange innerhalb des Hooks ausschließlich über $this->propertyName auf das eigene Backing-Field zugegriffen wird, verhält sich PHP korrekt und es entsteht keine Endlosschleife. Wird jedoch versehentlich ein anderer Hook aufgerufen, der wiederum den ersten liest, kann eine zirkuläre Abhängigkeit entstehen, die PHP nicht automatisch zur Kompilierzeit erkennt und die erst zur Laufzeit als Stack-Overflow-Fehler sichtbar wird.

Bei der Interaktion mit Serialisierung und Debugging-Funktionen gibt es ebenfalls Besonderheiten zu beachten. var_dump() und print_r() zeigen bei virtuellen Properties ohne Backing-Field keinen gespeicherten Rohwert an, sondern lösen unter Umständen den get-Hook aus oder markieren die Property als virtuell, abhängig von der PHP-Version und den verwendeten Debugging-Tools. Bei serialize() und der Serializable-Schnittstelle ist zu beachten, dass nur tatsächlich existierende Backing-Fields serialisiert werden, virtuelle Properties werden beim Deserialisieren aus den vorhandenen Feldern neu berechnet und müssen daher nicht separat behandelt werden, solange ihre Abhängigkeiten selbst serialisiert werden. Ein einfaches Beispiel verdeutlicht die Backing-Field-Regel: Eine Property public int $value { get => $this->value; set { $this->value += $value; } } greift in beiden Hooks korrekt auf das eigene Backing-Field zu und erzeugt keine Rekursion, solange kein anderer Hook zwischengeschaltet wird, der wiederum denselben Zugriff auslöst.

10. Zusammenfassung

Property Hooks lösen ein Problem, das PHP-Entwickler seit Jahren mit manuellem Boilerplate umschifft haben: Validierung, Normalisierung und berechnete Werte lassen sich jetzt direkt in der Property-Deklaration unterbringen, statt sie hinter separaten getX()/setX()-Methoden zu verstecken. Der get-Hook erlaubt sowohl transformierte Lesezugriffe auf ein bestehendes Backing-Field als auch vollständig virtuelle, nicht gespeicherte Properties. Der set-Hook zentralisiert Validierung und Transformation an genau einer Stelle, die nicht umgangen werden kann.

Für größere Codebasen sind besonders die Möglichkeiten in Interfaces und bei der Vererbung relevant: Ein Interface kann mit { get; } einen klaren Property-Vertrag definieren, und Unterklassen können mit parent::$prop gezielt auf Basisverhalten zugreifen, statt es zu duplizieren. Gleichzeitig bleiben reale Grenzen bestehen, etwa die fehlende direkte Hook-zu-Hook-Kommunikation und die Notwendigkeit, Caching bei teuren get-Hooks selbst zu implementieren. Wer diese Grenzen kennt, kann Property Hooks gezielt dort einsetzen, wo sie echten Mehrwert gegenüber klassischen Gettern und Settern bieten.

11. FAQ: Property Hooks in PHP 8.4