Wildcard in Abfrage ... oder so ähnlich ;)

[Sympathisant]

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.

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.

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()).

Dann ist da noch das Thema "Einarbeitung". Angenommen, es stoszen zu dem Team weitere Entwickler hinzu:
Arbeitet man sauber und durchgaengig mit Datenobjekten (und Klassen im Allgemeinen), so ist fuer den Entwickler die Einarbeitung um ein erhebliches leichter. Bleiben wir bei dem Beispiel des OP: Woher soll ein Entwickler wissen, welche Keys fuer den Array existieren? 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).
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.

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.

* Im Falle von PDO braucht man das Mapping nicht einmal selbst vorzunehmen. Siehe hierzu http://de.php.net/manual/en/pdostatement.fetchobject.php

MfG,
Sympathisant