fantast

ja sicher. und trotzdem stimme ich dem autor nicht zu. ich finde um eine saubere struktur zu erzeugen muessen membervariablen mit accessors ausgestattet werden. sei es auch nur ein return $variable;

habe ja die rekursive alternative dazu gegeben. und was waere denn deiner meinung nach eine bessere methode, um auf ein mehrdimensionales array, dessen genaue struktur man nicht kennt zuzugreifen ? einfach mal auf gut glueck keys probieren und dann fehler abfangen ?!?

wenn du deinen link oben genau laesest, wuerdest du auch folgendes entdecken: manchmal kommt man nicht ohnehin accessors zu schreiben. und wie schon erwaeht alleine der einheitlichkeit und damit der uebersichtlichkeit sollten in dem fall dann alle membervariablen accessors haben. imho.

__________________
Was ist validität?

Mister Ad

Waq

Um eine ordentliche Struktur zu erzeugen, sollte überhaupt nicht auf einzelne Member-Variablen zugegriffen werden, auch nicht durch einen Accessor. In den meisten Fäälen sind Accessoren ein Anzeichen auf eine nicht-OOP-Struktur, die sich ein OOP-Kleidchen angezogen hat.

Erstens ist deine Variante iterativ und nicht rekursiv. Zweitens wirkt sich das nicht auf den Zugriff von aussen aus, und genau der ist das relevante.

Wenn es eine Baumstruktur ist, sollte man es auch als Baum darstellen und nicht als Array. Bäume stellt man normalerweise durch Parent-Child-Verknüpfungen dar, z.B. wie ich beschrieben habe durch verschachtete Objekte. Wie beim DOM, nur viel schlanker.

Hier ist der Accessor, wie üblich, nur ein Hack, der einen zufriedenstellt, weil man ja OOP gemacht hat, der aber eigentlich nur verbirgt, dass man es besser machen könnte. Ohne direkten Zugriff auf eine einzelne Variable. Die Verantwortlichkeiten sind einfach falsch organisiert. Hier wird eine Entscheidung auf den Aufrufer übertragen, die vom Objekt selbst getroffen werden sollte. Wie meistens bei Accessoren...

__________________
mod = master of disaster

fantast

richtig. was machst du in dem fall, wenn man die variable direkt braucht ?

moment, jetz haste mich verloren, was is denn an meiner variante iterativ ? ich seh da keine iteration. oder hab ich das grundprinzip von rekursion falsch verstanden ?
zweitens: wieso sollte es denn auch ? ich will von aussen eine methode aufrufen, die mir meine variable liefert, nicht erst selbst rekursiv oder iterativ oder sonstewas werden muessen, oder ?

zugegeben, wenn hier tatsaechlich ein baum dargestellt werden soll, is das nich die optimale loesung, aber das hab ich mir ja auch nich ausgedacht :P

sprich dir waere es lieber wenn man in dem fall die methode nicht set() nennt sondern updateOnExternalMedium() aber den inhalt genau gleich laesst ? zugegeben, damit waere mehr transparenz gewaehrleistet, aber diese wieder zu lasten der uebersichtlichkeit.
ich habe eine klasse, die hat ein paar membervariablen, ob diese einfach lokale variablen sind, oder inner db liegen oder sonstwo ist mir als client doch erstmal voellig egal. ich will halt die variable haben. dazu rufe ich get() auf. wenn diese methode sich dann zur db verbindet, etc. is das doch nur in ordnung ?!?
sach an...

__________________
Was ist validität?

Waq

Überlegen, was ich falsch gemacht habe. Wie die "bessere" Struktur aussieht, ist vom Kontext abhängig. Meistens geht es in die Richtung, dass der Zugriff als atomarer Vorgang unnötig ist und in eine andere Funktion integriert wird, oder dass der Accessor erweitert wird und der aufrufenden Funktion Arbeit abnimmt, so dass der Aufrufer weniger über die Interna des Objekts weiss. Da ist es nicht mit einer Umbenennung der Methode getan.
Wenn einem keine bessere Struktur einfällt, lässt man es halt so.

Schleifen sind iterativ. Wenn eine Funktion sich selbst oder eine verwandte Funktion aufruft, ist das Rekursion.
Ein ordentlicher Zugriff auf einen Baum könnte so aussehen (aka SimpleXML):

Das Durchgehen der Kinder eines Knotens ist hier zwar noch iterativ, aber der Sprung von Ebene zu Ebene ist rekursiv. Das meine ich auch mit "von aussen".
Ich sehe einfach keinen Grund, warum sich der Aufrufer mit den Array-Indizes rumschlagen sollte, wenn es sich um eine Baumstruktur handelt.

__________________
mod = master of disaster

fantast

gut und dann schau dir bitte nochmal meine funktion an, die ist komplett rekursiv. da ist keine einzige schleife drin...

ausserdem gehst du ueberhaupt nich auf meinen punkt mit den accessors ein. ich gestehe dir zu, dass wenn es moeglich ist eine komplexere struktur zu schaffen, die die accessors ueberfluessig machen wuerde, dieser auch immer der vorzug gegeben werden sollte, aber wieso einfach, wenns auch kompliziert geht, nicht wahr ?

__________________
Was ist validität?

Mann, mann, da hab ich ja was losgetreten.

Um ein paar Sachen klar zu stellen:

1. Mir ist klar, daß das zuerst beschriebene Beispiel nicht der ideale Weg ist, eine Baumstruktur darzustellen. Dafür eignen sich Objekte deutlich besser. Abgesehen davon, daß bis PHP4 die Entscheidung für Objekte auch immer einen großen Performance-Verlust mit sich bringt, ging es aber hier nicht um die Praxisanwendung. Ich wollte einfach wissen, ob jemand eine bessere Methode hat, einen dynamischen Zugriff auf ein multidimensionales Array zu realisieren, da sich Array-Bezeichnungen nicht variabel bilden lassen.

2. Keines der hier gezeigten Beispiele ist wirklich rekursiv, stimmt, sie sind alle iterativ. Die Umsetzung wäre aber nun kein Problem und ändert am Prinzip meines Beispiels nicht viel.

@Waq, deinem Link bin ich gefolgt und habe den Artikel mit Interesse gelesen, auch wenn ich dem Autor nicht in allem zustimmen kann.

Natürlich werden Accessors zu häufig und oft ohne Sinn eingesetzt. Außerdem bin ich ebenfalls der Meinung, daß der Datenbestand einer Klasse grundsätzlich nicht public zu sein hat, ob über direkten Zugriff oder Accessors ist eigentlich egal. Dafür soll ein Objekt schliesslich ein UI zur Verfügung stellen. Es gibt allerdings Fälle in denen Objekte als Daten-Container fungieren. Nehmen wir mal als Beispiel ein Konfigurations-Objekt, dass eine Konfigurationsdatei parst und den Inhalt der gesamten Applikation (z.B. über Singleton) zur Verfügung stellt. In dem Fall kann man natürlich jede angeforderte Konfigurationsanweisung als Objekt zurück geben, dass die entsprechenden Daten enthält. Gerade in PHP4 halte ich das aber für Overkill.

OOP ist meiner Meinung nach im Praxiseinsatz kein starres Konzept, sondern ein Design-Prinzip, mit dem sich viel Arbeit sparen und sauberer entwickeln läßt. Wenn eine Ausnahme im üblichen OOP-Prinzip viel Arbeit sparen kann, fühle ich mich nicht, als hätte ich heilige Regeln übertreten.

P.S.: Ich habe hier niemanden rufen hören: 'Guck mal, tolles OOP'. Ich denke den Tonfalls können wir uns sparen, oder?

Nachtrag: Habe natürlich ein paar Beiträge vorher zu schreiben angefangen. Man sollte nicht zu viel gleichzeitig machen.

fantast

ich moechte immernoch darauf hinweisen, dass ich meine funktion sehr rekursiv finde
und das moechte ich bitte unterschreiben !

__________________
Was ist validität?

Waq

Oops... tatsachlich. Trotzdem ist die Rekursion auf der falschen Seite

Doch. Das war mein Hinweis auf den "Kontext". Ich fürchte, viel genauer kann man da nicht werden.

Gerade die Struktur soll ja durch das Entfernen des Accessors vereinfacht werden.

__________________
mod = master of disaster

Waq

Dann würde ich in PHP 4 eben eine Variante umsetzen, die mit einem zusätzlichen Objekt auskommt. Das hält den Performance-Verlust doch sehr klein.

Also nehmen wir an die bisherige Klasse heisst TreeArray, dann baue ich eine Helper-Klasse TreeArrayTraverser, die eine Referenz auf eine Instanz von TreeArray bekommt und direkt (ohne Accessoren, ist schliesslich eine Schwester-Klasse) auf das Array zugreift.
In das Ding implementiert man das gleiche Interface wie vorhin beschrieben, nur mit einer zusätzlich Methode für den Weg zur Wurzel zurück, darauf zuzugreifen sähe so aus:
Dazu bräuchte die Helper-Klasse einen Stack, aber den bräuchte sonst der Aufrufende Code. Man macht es sich so also nicht komplizierter als nötig, man verschiebt den Code nur dorthin, wo er sinnvoller ist, und sich so "nah" an den Daten befindet, dass er ohne Accessoren frauf zugreifen darf. Man macht es sich also sogar einfacher.

Mir fällt einfach kein Fall ein, wo man auf ein unbekanntes Multidimensionales Array durch einen Accessor zugreifen müsste, weswegen ich es nicht so schade finde, dass es dafür scheinbar keine einfache, performante Möglichkeit gibt.

__________________
mod = master of disaster

hi,

der erste würdige thread im profi forum denn ich bisher lesen konnte (:
die "why accessors are evil" diskusion habe ich schon in diversen foren
verfolgt unnd diskutiert.

von der theroie her ist das absolut valide und meines erachtens auch richtig die set/get orgien zu unterbinden. es gibt einen grundsatz der damit zusammenhängt : "tell, dont ask". es gibt aber (wie immer) einige ausnahmen (bsp ValueObjects) für diesen grundsatz. das zur theroie.

in der praxis aber arbeiten wir mit php - einer scriptsprache die auch noch auf einem webserver läuft und dem prinzip von "share nothing" folgt. das bedeutet für mich einen (manchmal anstregenden) mittelweg zwischen performance und optimaler objektorientierung zu suchen. unsere aufgabe besteht darin schnellstmöglich eine aufgabe zu erledigen und dabei im unterschied zu client applikationen auch noch die gesamte infrastruktur jedesmal neu aufzubauen. das heisst für mich im klartext das ich an einigen stellen meiner applikation bewusst design prinzipien verletze. damit meine ich aber nicht das array problem.. das hat waq schon sehr schön gesagt : das design stimmt da wohl nicht.

mir geht es um (jedenfalls für mich) komplexere themen wie zb einem objekt persistenz layer. du gehst ständig auf dem schmalen grad zwischen physikalisch gegebener rechenleistung und guter objektorientierung. für eine normale webseite mit normalem traffic könnte mann das denke ich aberschon hinbekommen. schwieriger wird es mit high traffic seiten oder webanwendungen. hier zählt vor allem anderen die reaktionszeit für den anwender. ich kenn das sogar von mir selbst - wenn irgend eine seite derbe ablahmt muss der content schon richtig sexy sein damit ich die regelmässig besuche.

ein ganz praktisches problem sind dabei zb interfaces bei php5. interfaces beschreiben einen quasi einen vertrag den jedes implementierte objekt erüllen muss. gute sache (für einige auch eine mehrfach vererbung lite) das... hat aber auch den haken das mann keine konstruktoren in einem interface deklarieren sollte. falls mann das tut kann die klasse dann immer nur ein interface mit einem konstruktor implementieren.. irgendwie nicht ganz so prall imho. das führt dann wieder zu den heiss geliebten accessoren:

alles in allem würde ich momentan sagen : mach es wie es passt aber vergiss das refactoring nicht und schreib immer schön tests (tdd). wenn du dann noch versuchst immer erst mal die einfachen wege zu gehen endet das bei sauberem, fehlerfreierem ( ? ) und vor allem weniger code. hört sich für mich persönlich nach nem guten deal an (;

gruss
Sike

Mister Ad