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

Beitrag lesen

Hallo,

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.

Naja, man mag sich fragen, ob das eben so schlau ist. Bei c# definierst du das ja auch. Das "sollte" man bei PHP vielleicht auch so machen, dass Objekte/Klassen den Zugang zu Daten via get/set bewerkstelligen.

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.

Das mag sein. Wobei die Übersicht ja ggf. auch damit zusammenhängt, ob ich vielleicht nur ein paar Ausnahmen habe, die ich über __get/set regele.

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.

Naja, active-record wäre das dann, oder? Kann sein, muss nicht. Dann regelt die Klasse den Zugriff auf die Datensätze, oder? ZF kennt auch eine DB_Row-Klasse glaub ich. Aber fetchAssoc() gibt bestimmt die Zeilenwerte als assoziatives _Array_ wieder.

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.

Ne. Ein Objekt ist ja in dem Sinne kein Datensatz, sondern der Datensatzverwalter. Oder muss es nicht sein. Verwaltet es sich selbst, ist active-Record, hätte ich jetzt gemeint. Aber dann hast du u.U. auch wieder die Iterationsprobleme. Auf einzelne Vars gezielt zuzugreifen (getId()) ist dann u.U. auch über getter nicht falsch. Denn dabei definierst Du ja auch kein offenens Regal, an dem sich "jeder" bedienen kann, wie und wann er will, sondern gibts strukturierten Zugriff vor.

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.

Wenn Foo fürs Lesen und Schreiben verantwortlich ist, dann sollte die Klasse genau das tun. Ob sie die Werte, die sie schreibt und liest innerhalb der Funktion dass dann als $_bar oder $_baz abspeichert, ist privat. Denn da die Klasse fürs Lesen und Schreiben zuständig ist, nimmt sie Parameter fürs Lesen entgegen und gibt Daten (i.d.R.) als Array oder Einzelwerte zurück. Oder übernimmt Daten als Array oder Objekt und weiß dann, was damit zu tun ist. So hätte ich das jetzt verstanden.

Gruß

jobo