Hello,

if( isset( $myOffice->GetAddress() ){}
Wie bitte?
War die Kurzform - es sollte nur der Veranschaulichung dienen.

Da PHP nicht faehig ist, den Rueckgabewert einer Methode direkt zu verwenden, muss man den Wert vorher natuerlich einer Variablen zuweisen.

Eine "Methode" hat nur dann einen Rückgabewert, wenn sie auch als "Funktion" definiert wurde und nicht nur als "Prozedur", um mal diese gutan alten Museumsbegriffe zu bemühen.

Die Deklaration sieht in PHP ja leider immer gleich aus, zumal man sie gar nicht mehr aktiv wahr nimmt, da auch Methoden implizit deklariert werden, also durch ihre Definition.

Es muss also einfach ein Rückgabewert mittels 'return' erzeugt werden.

Bevor Du OOP benutzt, solltest Du vielleicht erst mal einen Grundkurs in klassischer Programmierung machen, sonst passiert nämlich genau das, was ich hier immer proklamiere: OOP wird nur benutzt, weil es chic ist und aus reinem Selbstzweck...

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

Hallo,

Hai eddi,

das ist für den ersichtlichen Einsatz fast schon unschlagbarer code blow up.
Das sehe ich gar nicht so.
In der Praxis werden Applikationen kontinuierlich erweitert. Und man sollte sich nicht bereits am Anfang der Moeglichkeit entziehen, zukuenftige Anforderungen oder Aenderungen mit dem geringsten Aufwand implementieren zu koennen. Der vom OP gepostete Code sieht sehr danach aus, als kaemen die Daten aus der Datenbank.
Zudem sieht es so aus, als handle es sich um Kundendaten (er nannte eine Variable "Office").
Und da Kundendaten in einer Applikation selten an einer einzigen Stelle referenziert werden, koenne wir davon ausgehen, dass der Zugriff auf das Array noch an weiteren Stellen im Code erfolgen wird.

Schlichtweg ist der Gebrauch einer Datenbank eben sowenig Argument der Vorteile von Objekten wie auch Mehrfachzugriffe.

Und Zugriffe auf dynamische Datenstrukturen mittels assoziativer Arrays sind fehleranfaellig. Hierfuer gibt es viele Gruende. Einer davon ist, dass ein potentieller Fehler erst zur Laufzeit auffallen respektive auftreten wird. Zur Compilezeit steht nicht fest, ob der angegebene Key in dem Array ueberhaupt existiert. Ein weiterer Grund ist die allgemeine Reduzierung des Fehlerpotentials. Denn bei der Verwendung von Strings als Identifier koennen ganz leicht Rechtschreibfehler auftreten.

Hier notierst Du doch auch isset(), warum also soll isset($obj->return_val()) weniger fehleranfälliger als isset($array['key'])) sein? Was verleitet im Falle genutzter Objekte weniger zu Schreibfehlern bei Methodennamen?

Dann waere da noch die Wartbarkeit. Angenommen, der Key aendert sich aus bestimmten Gruenden. Dann muesste ein projektweites Refactoring stattfinden. Und das nur, weil aus dem Wort "strasse" das wort "strasse_1" geworden ist. Im Falle eines Datenobjektes muessten wir nur eine einzige Stelle im Code anpassen (und zwar genau dort, wo die Daten der Datenbank auf das Datenobjekt gemapped werden*), denn saemtliche Zugriffe laufen ueber einen wohl definierten Methodeaufruf ($Customer->GetStrasse()).

Was ist an $array['key'] schlechter wartbar $obj->$strin_name()? Würde sich Sting 'key' verändern, ist dies nicht adäquat zu Veränderungen von Objekteigenschaften sondern zu Methodennamen. Du vergleichst schlichtweg Äpfel mit Birnen. Passend wäre ein Vergleich der Erweiterung vom Datenfeld um ein Schlüssel-Werte-Paar zur Erweiterung eines Objekts.
 Aber sei's drum: Bei Umbenennungen innerhalb des Codes, wie die angeführte Änderung von 'key' in $array['key'], lässt man aus Gründen von Schreibfehlern eine Tokenizerapplikation kurz das Projekt parsen und anpassen.

Dann ist da noch das Thema "Einarbeitung". Angenommen, es stoszen zu dem Team weitere Entwickler hinzu:

Oben versuchst Du noch am Beispiel Argumente aufzustellen, während Du Dich jetzt vollends davon lossagst, um Objekten den zumindest aus Deinen Argumenten nicht ersichtlichen Vorteile zuzusprechen.

Arbeitet man sauber und durchgaengig mit Datenobjekten (und Klassen im Allgemeinen), so ist fuer den Entwickler die Einarbeitung um ein erhebliches leichter.

Das ist eine unbegründete Parole.

Bleiben wir bei dem Beispiel des OP: Woher soll ein Entwickler wissen, welche Keys fuer den Array existieren?

print_r($array); - was die Laufzeit anbelangt; und ansonsten ist die ordnungsgemäße Kommentierung seines Codes einem sich selbst erklärenden Interface absolut ebenbürtig, was die Einarbeitung betrifft. Das Argument der blow ups lastet dann aber noch gewichtiger.

Moechte er das in Erfahrung bringen, so muss er sich auf die Suche begeben.
Nutzt man statt dessen jedoch Datenobjekte, so bedarf es nur einen Blick in die entsprechende Klasse (arbeitet man mit guten IDEs braucht man nicht einmal das zu tun, da sie einem bereits die Methoden des Objektes anzeigen).

Ähm... Aua!
Eine Integrierte Entwicklungsumgebung, die klassen besser visoalisiert als Datenfelder, würde ich nicht als "gut" bezeichnen.

Ein Unterpunkt hierzu ist die Moeglichkeit (korrekt kommentierte Klassen vorausgesetzt), sich mit einfachen Mitteln sogar eine API der Anwendung erstellen zu lassen.
In der Praxis gewichten die Resultate der oben aufgelisteten Punkte hoeher, als die Befuerchtung des "code blow ups".
Zudem sehe ich durch die Verwendung von Datenobjekten nicht die Tatsache, dass der Code "aufgeblaeht" wird. Im Gegenteil, sie fuehrt sogar zu mehr Uebersicht und Struktur.

Wenn man sowieso schon auf dem Auge für KISS blind ist, reicht das sicher auch als Argument.
 Ich weis nicht, wie der PHP-Programmierer von heute stereotypisch aussieht. Sitzt der von einem Appel und braucht der alles bunt und schön, oder sitzt der vor einer Konsole mit vim und kann auch mit var_dump() oder eigens geschriebene Klasseniterationen umgehen?

Somit spart man sich das ewige Nachschauen, welche Keys ein Array denn wohlmoeglich haben koennte.
if( isset( $myOffice->GetAddress() ){}
Wie bitte?

Da PHP nicht faehig ist, den Rueckgabewert einer Methode direkt zu verwenden, muss man den Wert vorher natuerlich einer Variablen zuweisen.

Diese Variable muss dennoch überprüft werden, ob sie Inhalt enthält. (Punkt)
Du weigerst Dich Dein eigens ins Spiel gebrachte Argument ("Somit spart man sich das ewige Nachschauen, welche Keys ein Array denn wohlmoeglich haben koennte.") mit Deinem kurzformulierten Beispielcode als unvereinbar in Verbindung zu bringen. Das ist keine Diskussionsgrundlage!

Entschuldige bitte aber dem seit mehreren Jahren sich hier in diesem Forum breitgemachten Predigen von unreflektiert übernommenen Lehrsätzen, muss IMHO wieder mehr Objektivität - nicht Objektorientierung - entgegengestellt werden.

Gruß aus Berlin!
eddi

Hi!

if( isset( $myOffice->GetAddress() ){}
Wie bitte?
War die Kurzform - es sollte nur der Veranschaulichung dienen.
Da PHP nicht faehig ist, den Rueckgabewert einer Methode direkt zu verwenden, muss man den Wert vorher natuerlich einer Variablen zuweisen.

Diese Aussage ist falsch. Rückgabewerte einer Funktion können seit PHP 5 sehr wohl direkt verwendet werden, wenn du damit meinst, dass man auf die Methoden oder Eigenschaften eines zurückgegebenen Objekts zugreifen kann - so wie es deine nächste nicht mehr zitierte Zeile zeigt.

Aber: Die Funktion isset() prüft auf das Vorhandensein einer Variablen, weshalb sie eine Variable erwartet. Etwas anderes zu übergeben, erzeugt einen Parse Error. Wenn deine Variable OfficeInstanz->$Address nicht gesetzt ist, so liefert ein Lesezugriff null zurück. Außerdem gibt es eine Notice, was immer ein Zeichen für eine Schludrigkeit ist. Dieses null gibt deine Getter-Methode zurück. Legtest du es in einer Variable ab, so sollte man meinen, durch den Schreibzugriff existiere diese Variable. Das macht sie auch in der Tat, nur PHP meint beim isset(), dass eine existierende Variable mit Inhalt null nicht existiert. Auf dieses Verhalten PHPs sollte man nicht bauen, finde ich, weil es zu sehr verwirrt. Man setzt eine Variable und fragt im nächsten Moment, ob sie existiert, liest sich so, als traue man PHP beim Variablenerzeugen nicht übern Weg. Erst wenn man diese isset()-Ausnahme kennt, wird einem das Verhalten klar. Schöner wird es dadurch aber nicht.

Lo!