Warum Getter und Setter verwenden

Getter und Setter geben Dir als Entwickler die Möglichkeit der Validation von Eigenschaften.

Wenn man public Eigenschaften hat, können die nicht nur direkt gelesen, sondern auch beschrieben werden.

Deshalb setzt man die Eigenschaft auf private oder protected, je nach Bedarf und Vererbungsfähigkeit. Mit der passenden Setter-Methode kann dann der Wert zunächst validiert werden, bevor dieser der Objektinstanz zugeordnet wird.

Und da die Eigenschaft nun nicht mehr public ist, nutzt man eine Getter-Methode. Die Getter Methoden haben natürlich auch den zusätzlichen Vorteil, dass die Rückgabe noch bearbeitet, gecastet o.ä. werden kann.

Geht mir genau so. Sofern es sich um das reine Setzen und Auslesen einer Variablen handelt, kann ich keinen Nutzen erkennen. Anders sieht es aus, wenn zwingend mit dem Setzen der Variablen weitere Aktionen verbunden sein müssen, z. B. Variable abc setzen erfordert gleichzeitig Aktion x und Aktion y. Dann ist ein Setter durchaus sinnvoll.

Zitat von Sempervivum

Sofern es sich um das reine Setzen und Auslesen einer Variablen handelt, kann ich keinen Nutzen erkennen.

Du siehst also wirklich den Nutzen nicht, wenn man öffentliche Eigenschaften einer Objektinstanz mit jedem beliebigen Wert frei setzen kann?!

Das ist schade, aber jeder wie er mag...

Etwas spät, aber ...

So in etwa.

Aber "Überschreibgefahr" nicht. Denn das ist oft gewollt.

Bsp: ein "Tool"

class Tool
{
    /**
     * @var int
     */
    protected $value = 1;

    /**
     * @param string $value
     *
     * @return $this
     */
    public function setValue($value)
    {
        if (!$this->isValidValue($value)) {
            throw new \InvalidArgumentException("Invalid value '$value' given!");
        }
        $this->value = (int)$value;
        return $this;
    }

    /**
     * @return int
     */
    public function getValue()
    {
        return $this->value;
    }
}

Angenommen, das Tool willst Du überschreiben:

class MyTool extends Tool
{
    /**
     * {@inheritdoc}
     */
    public function setValue($value)
    {
        $this->doSomethingBefore($value);
        parent::setValue($value);
        $this->doSomethingAfter($value);
        return $this;
    }

    /**
     * {@inheritdoc}
     */
    public function getValue()
    {
        $value = parent::getValue();
        if ($value >= 10) {
            $this->log("Just wanna mention that value is >= 10"); // :)
        }
        return $value;
    }
}

Du hast also mehr Möglichkeiten|Kontrolle.

Alle, die das Objekt benutzen, müssen die Setter und Getter nutzen, um Values zu setzen|ändern.

Du weißt also immer, wo die "ankommen" müssen. Und dort kannst Du ansetzen, um etwas zu ändern.

Wenn alle nur auf die Eigenschaft $object->value = 13 gehen würden, dann könntest Du das gar nicht nachvollziehen.

BTW: ich hab irgendwo gelesen, dass das eingeführt würde, um Typen (int, string, ...) zu setzen|validieren.

Mit der nächsten PHP Version solle das nicht mehr nötig sein, da man dann die Eigenschaften per Typ definieren kann.

Bsp: public int $value; (wenn ich mich nicht irre).

in dem Artikel hies es, dass Getter und Setter dann ~"endlich ein Ende hätten"~ - find ich aber Quark.

Getter und Setter sind ja nicht nur zur Validierung. Oft will man einfach noch was anhängen, filtern, loggen, ... .

Zitat von cottton

Getter und Setter sind ja nicht nur zur Validierung. Oft will man einfach noch was anhängen, filtern, loggen, ... .

Korrekt. Ein weiterer Vorteil ist halt, dass man aufgrund von Projektwachstum und -veränderungen Anpassungen auch an Eigenschaften von Objekten hat. In dem Fall müssen maximal nur die Getter und Setter angepasst werden und nicht das Script an sich, dass die Objekt-Instanz verwendet.

Wer den Nutzen nicht erkennt, sollte sich nochmal mit OOP Grundlagen befassen... Meine Meinung...