nicht angemeldet
echo $begrüßung;
ich programmiere ein CMS in php5[1]. Das ganze basiert auf einem eigenen Framework.
[...] Bei diesen Aufgaben werden mehrere Objekte miteinander verknüpft und dadurch in Abhängigkeit gebracht.
[...] Dabei werden schon (mindestens) drei Klassen miteinander verquirlt, die ich eigentlich ganz gerne unabhängig voneinander hätte.
Und jetzt die Frage: Wie macht Ihr das?
Frameworks, die ich einsetze, sind so gestaltet, dass sie in sich abgeschlossen sind, aber beliebig auf Klassen/Pakete ebendieses Frameworks zugreifen können. Diese Abhängigkeiten sind dokumentiert und müssen, wenn es sich um ein paketbasiertes Framework wie PEAR handelt, bei der Installation berücksichtigt werden.
Hinzu kommen allgemeine Funktionalitäten, die ich selbst programmiere und quasi eine Erweiterung des obigen Frameworks darstellen, mit diesem also verknüpft und von ihm abhängig sind. Es ist auch schon vorgekommen, dass ich das Framework gewechselt habe (z.B. von PEAR auf Zend Framework (noch immer im Preview-Zustand aber schon brauchbar)). Dann werden einge Funktionalitäten obsolet, andere müssen umgeschrieben werden und weitere neu entwickelt werden.
Die eigentliche Applikation greift auf beides zu und hat auch noch anwendungsspezifische Klassen, die miteinander agieren. Stellt sich heraus, dass eine Funktionalität so allgemein ist, dass auch andere Anwendungen davon profitieren können, wandert sie einen Absatz nach oben. Ist sie nur allgemein für diese Anwendung kommt sie "nur" in eine Elternklasse.
- baut Ihr eine große Helperklasse, die auf alle Objekte Zugriff hat?
Wenn du einen Vermittler zwischenschaltest, bringt das eine weitere Ebene mit zwei Schnittstellen (Daten bekommen und verteilen) ins Spiel, die natürlich auch wieder eine potentielle Fehlerquelle darstellen. Vermeide solche Zwischenschichten wo immer es geht. Nicht vorhandener Code benötigt keinen Pflegeaufwand und keine Ausführungszeit.
Wenn du Aufgaben mit dem Gedanken separierst, diese zwecks Lastverteilung später auf eine extra Maschine auslagern zu können, so solltest du bedenken, dass ein Prozeduraufruf im selben Prozess um einiges schneller abläuft als ein Zugriff auf einen anderen Prozess oder gar ein Fernzugriff. Deshalb sollten Fernzugriffe so gestaltet sein, dass sie wenig aufgerufen werden müssen. Dementsprechend grob muss die Schnittstelle aussehen. Statt einzelner Zugriffe auf Eigenschaften eines Objekts mit jeweils einem RPC (Remote Procedure Call) ist es günstiger das gesamte Objekt zu übertragen so dass diese Einzelzugriffe lokal stattfinden.
Eine Abschottung einer Funktionalität durch eine API-Schicht setze ich erst dann ein, wenn es sich aufgrund der Aufgabenstellung nicht vermeiden lasst.
OOP-gerechtes Programmieren ist chic. Die OOP-Theoretiker denken sich immer mehr Dinge aus, die gut aussehen. Doch nicht immer ist es vom praktischen Standpunkt aus sinnvoll, Dinge, die in reinen OOP-Umgebungen erfunden wurden, auch auf PHP zu übernehmen. PHPs Philisophie ist mitunter einfacher. Man muss beispielsweise keine Collection nachbauen, wenn es ein einfaches Array auch tut.
Bei jedem Muster, das ich einsetze, frage ich mich, ob im konkreten Fall der Code-Mehraufwand den Einsatz rechtfertigt. Ich habe keine sturen Prinzipien à la: "jede Eigenschaft braucht ein Setter/Getter-Paar". Bei mir bekommt sie das nur wenn es nötig ist und mehr als nur ein Wert gesetzt/gelesen werden soll[*]. Usw. usf. Jeder Codeteil muss sich bei mir die ISDN-Frage gefallen lassen: Ist Sowas Denn Nötig? Die Beantwortung derselben setzt natürlich Erfahrung voraus, die sich bei mir auch aus Erkenntnissen von beschrittenen Irrwegen angesammelt hat.
echo "$verabschiedung $name";
[*] In diesen Satz kann man zwei Bedeutungen interpretieren:
- mehr als ein Wert: also zwei oder mehr
- es werden noch andere Dinge ausgeführt als (den) Wert(e) zu setzen/lesen
Beide Bedeutungen sind gemeint.