Tach,
(und nein, das liegt nicht an meiner Programmierunerfahrenheit, mit den von dir genannten Jahreszahlen kann ich durchaus mithalten).
Doch, genau daran liegt es.
und das kannst du aufgrund deiner kürzeren Programmmiererfahrung sagen?
Lass Dich nicht beeirren und nicht durch Fachbegriffe verwirren.
Das du das nicht tust, ist mir schon klar, sonst würdest du nicht so viele Fachbegriffe in falschen Zusammenhängen und mit falschem Inhalt befüllt verwenden.
Mein FW ist letztendlich ein Ergebnis meiner eigenen Beharrlichkeit und meines Selbstvertrauens. Letzteres ist ein ziemlich starkes Motiv und auch das Alles Entscheidende.
Genau so kommt es rüber, du bist der einzige, der die Weisheit mit Löffeln gefressen hat und alle, die dich kritisieren, müssen dementsprechend falsch liegen.
Kommen wir mal zu einer einfachen Sache, die Bindung eines URLs an eine Subklasse. z.B. in einer INI-Datei
; URL, Klasse u.a. Attribute
[/sitemap.xml]
class=Sitemap
no_cache=1
no_sitemap=1
Diese u. weitere URLs bilden, nachdem die ini im RAM gelandet ist, den sog. urlmap oder auch Routing-Table genannt. Ich darf die ini natürlich auch Projektverwaltung nennen, weil da alles, was sich auf einer Domäne befindet, drinsteht.
So reicht zur Qualitätssicherung und Debug ein flüchtiger Blick in den Response-Header, um zu sehen, an welche Klasse ein URL gebunden ist, der Customheader lautet x-class.
Nachdem also die Klasse feststeht, wird Sitemap.pm kompiliert und eine Instanz dieser Klasse erstellt.
class Sitemap wiederum erbt von package main ein Interface.
Interfaces werden in Klassen implementiert, nicht geerbt, von einem Interface erben können nur Interfaces.
Bei der Instanzerstellung werden weitere Klassen kompiliert und wiederum deren Instanzen eingbunden. Z.B. eine Instanz der Klasse CGI womit Requestparameter befragt werden können und eine Instanz der Klasse SESSION kurz class SES.
Das Reinschmacken dieser fremden Objekte in mein FW-Objekt nennt sich Aggregation.
Je nachdem, was du mit „Reinschmacken“ meinst, könnte das richtig sein.
Delegation ist, wenn eine zum FW-Objekt also zur eignen Subklasse gehörige Methode über solche inneren Instanzen Methoden der fremden Klasse aufruft.
Z.B. $self->{SES}->write(); um die Sessiondaten auf die HDD zurückzuschreiben.
Ich verstehe zwar nicht, warum eine einen Seitentyp implementierende Klasse das selber implementieren sollte, aber zumindest ist es ein Beispiel für Delegation; das Session-Object sollte im Allgemeinen selbst genug Informationen darüber haben, ob es persistiert werden sollte (z.B. in Java im Rahmen einer close-Funktion).
Und Lazy Delgation ist, wenn Instanzen nicht verwandter Klassen später, also erst zur Laufzeit in das FW-Objekt als Attribut reingeschmackt werden. Gewöhnlich im Rahmen einer Factory.
Meinst du vielleicht lazy initialization?
Dependency Injection
Ob du in diesen Paragraphen irgendwo Dependency Injection genutzt hast, ist mindestens unklar, du hast zwar Prozesse beschrieben, wo es sinnvoll wäre, aber kein Beispiel dafür genannt.
Das ist im Prinzip schon alles. Logisch: Wenn ich nur die Config-Daten brauche, muss das Attribut {CFG} an keine Klasse gebunden sein.
Will mein FW-Objekt jedoch CFG-Daten persistent machen, muss das Attribut {CFG} bzw. die Daten in dieser Referenz an eine Klasse gebunden sein, denn die Klasse definiert den Speicherort.
Die Konfiguration sollte den Speicherort vorgeben, nicht eine Klasse. Und dass das Schreiben einer Konfiguration im Rahmen der von dieser Konfiguration betroffenen Applikation keine gute Idee ist, hatte ja Sven in einem anderen Thread in dieser Woche schon erwähnt: https://forum.selfhtml.org/self/2016/mar/21/wie-am-besten-konfigurationsparameter-uebergeben/1663691#m1663691
Perl realisiert sowas über tie() das bindet eine Variable an eine Klasse und das geht auch in PHP zu machen wenn auch viel umständlicher.
tie ist eine Möglichkeit in Perl Klassen hinter einem festgelegten Interface zu verstecken (bzw. einem von vier ähnlichen Interfaces) und ob es der jeweils richtige Weg ist, muss im Einzeelfall entschieden werden.
mfg
Woodfighter