nicht angemeldet
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
Wenn der Weg zur Hölle mit guten Vorsätzen gepflastert ist, wäre der zum Himmel aus bösen Absichten betoniert. Was aber ist dann ein Weg voller Irrtümer?
Wer weiß - vielleicht der Mittelweg. ;)