dedlfix: einzelne Getter oder eine Methode - Datenrückgabe Struktur

Beitrag lesen

Hi!

Ich sehe auch, wenn eine les- und schreibbare Eigenschaft public ist, dass man darauf zugreifen darf.
Davon gibt es aber fast keine, hätte ich jetzt gemeint.

Ich meinte das nicht speziell auf das ZF bezogen sondern allgemein.

Am besten von den mir bekannten Sprachen finde ich das bei C# gelöst.
... Getter und Setter werden direkt der Property hinzugefügt und sind nach außen hin nicht sichtbar.
Naja, ich meine, dass du mit __get den selben Effekt erreichen kannst.

Jein, nur indirekt. Das Ergebnis ist das gleiche, aber es ist wesentlich unübersichtlicher, mit nur je einer __get() und __set()-Methode pro Klasse alle Eigenschaften behandeln zu müssen. Auch dann, wenn man sie nur als Dispatcher verwendet und die eigentliche Zugriffslogik in einzelne Methoden auslagert. Sie liegen dann ja auch nur lose in der Klasse rum und sind nicht direkt mit Syntaxelementen an einen Eigenschaftenname gebunden. Da letzerer auch nicht mit Code deklariert ist, kann er auch nicht von IDEs zwecks Autovervollständigung erkannt werden. Dazu muss man Spezialkniffe mit Dokumentationskommentaren verwenden, die aber auch nicht von allen PHP-IDEs berücksichtigt werden.

In der Vergangenheit wollte ich selten über alle Eigenschaften eines Objekts iterieren.
Nee, aber du willst vielleicht doch auf das Objekt zugreifen (können).

Ja, und zwar so wie das eigentlich vorgesehen war, auf einzelne Methoden und auch Eigenschaften, ohne umständliche Getter/Setter, wenn das nicht notwendig ist.

Dispatcher::getInstance()->getRequest()->getParams(); so in der Art hätte ich gedacht. Die Instanz vom Dispatcher ermöglicht den Zugriff auf das Request-Objekt, welches wieder über getParams() ein Array(!) der Paramenter, vielleicht assoziativ, wiedergibt.

Das ist ein Array mit Daten drin, ohne dass dazu ein Objekt existiert. Das ist so in Ordnung, aber die Eigenschaften eines Objekt über ein Daten-Array bereitzustellen, allein zum Zwecke ihres normalen Zugriffs, ist schon ziemlich unpraktisch.

Der Iterator verwurstet doch Arraykonstruktionen, oder?

Ein Iterator liefert Daten in sequenzieller Form, wenn man sie in einer solchen benötigt. Von außen gesehen sieht das wie das Iterieren über ein Array aus, aber ansonsten ist die Implementation des Iterators nach Belieben gestaltbar. Man könnte beispielsweise eine foreach-Schleife haben, die normalerweise mit Arrays gefüttert wird, der man aber nun die Ergebnismenge aus einer Datenbankabfrage übergeben will. In ein Array fetchen und dieses übergeben ist eine (speicherverbrauchende) Möglichkeit. Eine andere ist ein Iterator, der bei jedem Schritt einen Fetch-Aufruf durchführt und den dabei gewonnenen Datensatz liefert.

Übrigens, wenn man sich das Erstellen von zwei Methoden pro Eigenschaft ersparen will, kann man Getter und Setter auch in einer Methode kombinieren:

class Foo {

private $bar;

function Bar($value = null) {
    if ($value != null)
      $this->bar = $value; // oder eine komplexere Schreiblogik

return $this->bar; // oder eine komplexere Leselogik
  }
}

$qux = $foo->Bar(); // Lesen
$foo->Bar('baz'); // Schreiben

Der Nachteil an dieser Lösung ist, dass nicht eindeutig zwischen Schreib- und Lesezugriff unterschieden werden kann. Wenn $value gleich null ist, dann ist es ein Lesezugriff. Wenn er ungleich null ist, ist es ein Schreibzugriff, kann aber auch ein kombinierter Schreib-Lese-Zugriff sein. Man kann nicht innerhalb einer Methode feststellen, ob der Rückgabewert vom Aufrufer verwendet wird oder nicht. Bei einem reinen Schreibzugriff wird also eine komplexere Leselogik jedes Mal mit ausgeführt.

Lo!