Klasse aus Datenbank füllen, danach die Klasse verarbeiten

[dedlfix]

Tach!

Ich wollte schon das gleiche erzählen, aber du bist mir zuvor gekommen. Stattdessen nütze ich den Thread, um ein wenig über Design-Entscheidungen zu plaudern und hoffe, dass man mich dafür wehement kritisiert.

Für das falsch geschriebene vehement könnte ich dich kritisieren, aber für die fachliche Diskussion brauche ich dieses Adjektiv nicht.

Die Modellklasse für einen Proof könnte in PHP z.B. so aussehen:

<?php

namespace Demo\Domain;

final class Proof
{
    private int $id;

    private string $title;

    private int $price;

    public function __construct(int $id, string $title, int $price)
    {
        $this->id = $id;
        $this->title = $title;
        $this->price = $price;
    }

    public function getId() : int
    {
        return $this->id;
    }

    public function getTitle() : string
    {
        return $this->title;
    }

    public function getPrice() : int
    {
        return $this->price;
    }
}

Die Propertys mit Typ auszuzeichnen ergab (in PHP 7.2) einen Fehler. Das hab ich auch im Handbuch so nicht gefunden.

Das ist natürlich ne Menge Schreibarbeit für eine reine Datenklasse, die keine Geschäftslogik enthält. Man hätte sich die getter-Methoden sparen können und dafür die Attribute public machen können. Das ist eine freie Design-Entscheidung, ich persönlich bevorzuge unveränderliche Objekte, und habe mich daher für dieses Design entschieden und die Tipparbeit in Kauf genommen.

Hier mal meine Variante:

class Proof
{
    private $id;

    private $title;

    private $price;

    public function __construct(int $id, string $title, int $price)
    {
        $this->id = $id;
        $this->title = $title;
        $this->price = $price;
    }

    public function __get($name)
    {
        return $this->$name;
    }
}

Weniger Tipparbeit und man muss nicht unterscheiden, ob man $x->getFoo() oder $x->foo schreiben muss. Man kann noch mehr Fehlerbehandlung in __get() einbauen, aber die hauseigenen PHP-Meldungen reichen im Prinzip aus, um unzulässige Zugriffe zu erkennen. Ein __set(), das eine Exception wirft, wäre vielleicht noch sinnvoll, denn ohne dies kann man beliebige Eigenschaften hinzufügen, die andere Namen haben als den privaten Eigenschaften.

Mit dem Magic Getter geht leider der Type Hint für den Variablentyp verloren, aber ich glaube mich zu erinnern, dass es da PHPDoc-Syntax gibt, um solche versteckten Eigenschaften der IDE bekanntzugeben.

Eine andere Design-Entscheidung von mir ist die Klasse mit final auszuzeichnen. Das ist in diesem Fall auch rein meinen persönliche Vorlieben geschuldet: ich bevorzuge Komposition gegenüber Vererbung, deshalb öffne ich meine Klassen nur für Vererbung, wenn ich sie wirklich mal brauche.

Selbst wenn ich sie als final ansehe, würde ich dieses Schlüsselwort nicht setzen wollen. Was stört es mich denn, wenn ein Verwender davon erbt, wenn das unbedingt gewünscht ist? Aus welchem Grunde muss ich das aktiv verhindern? Ich selbst werde wohl nicht auf die Idee kommen, eine Vererbung zu verwenden, geschweige denn es unbeabsichtigt zu notieren, wenn das meine bevorzugte Variante wäre.

dedlfix.