nicht angemeldet
Manchmal habe ich echt das Gefühl das ich ganz andere Sachen schreibe oder Sage, wenn ich mir nur die Antwort angucke (Vor allem bei meiner Frau...hmpf). Hier ist wieder so ein Punkt:
Ich habe das System kritisiert, nicht dich.
Die Antwort würde ich erwarten wenn ich gesagt hätte "du bist nicht nett zu mir". Ich hab aber geschrieben "Also ich finde deine Antwort nicht gerade nett.". Es ist also irrelevant ob du schreibst dass der Autor ein Arsch ist oder sein Buch schlicht Zeitverschwendung sei. Und das ich deine Antwort nicht nett finde liegt wahrscheinlich daran, dass du sehr viel in mein System hineininterpretierst was du jedoch gar nicht wissen kannst. Und nein dass muss man nicht machen nur weil der andere wenig über sein System erzählt.
Aber mal zur Sache.
Ein einziges Singleton reicht schon, damit das Leben nicht mehr so schön ist.
Gutes Argument! Mich verwirrt ein wenig dass du strikt dagegen bist später aber:
Ich bin sehr dafür, Konfigurationsdaten und Programm strikt zu trennen. Ob nun als Singleton oder sonstwie gelöst: Diese Klasse liest einmal die Konfiguration ein und liefert die darin definierten Werte aus. Fertig.
Aber vielleicht ist das die Erkenntnis das man nicht strikt gegen etwas sein kann sondern immer den Anwendungsfall sehen muss. Ich hab heute morgen z.B. eine Importdatei geschrieben, welche eine CSV Datei in eine Datenbank einliest. Keine Funktionen, keine Klassen alles von oben nach unten. Am Ende hab ich 100 Zeilen die einfach funktionieren. Was sagst du, wenn ich noch eine Importdatei bräuchte müsste ich alles nochmal machen. Recht hast du. Und soll ich dir was sagen, die 3 Importdateien die ich dieses Jahr gemacht habe sind in der Tat ähnlich. Sollte das ganze irgendwann mal größere Ausmasse annehmen kann man immer noch über OOP nachdenken. Um hier Vorurteilen vorzubeugen sei erwähnt dass dies nicht meiner normalen Herangehensweise entspricht. Ich möchte mit diesem Beispiel nur klar stellen das der Anwendungsfall eventuell Ausnahmen mit sich bringt.
Ein Defaultwert ist für mich essenziell wichtig. Der Idealfall ist, dass ein Programm immer weiß was der Anwender machen möchte. Das dies nicht realisierbar ist, liegt auf der Hand, es sollte jedoch ein Anstreben sein. Star Trek Fans werden das Wort "Notenergie" wahrscheinlich zugenüge gehört haben. Ein Defaultwert ist der Zustand (Notenergie) in den etwas fällt (z.B. ein Objekt), wenn alle Stricke reißen.
Vorteil:
- etwas funktioniert mit möglichst geringer Konfiguration
- weniger Exception Behandlungen
- wahrscheinlich einfachere Aufrufe (in deinem Fall müssen ja immer alle Parameter bekannt sein)
Nachteil:
- Objekte laufen mit Defaultwerten, auch wenn man das nicht möchte...
... als Beispiel bei dem Cookie. Wenn man vergisst einen speziellen Wert zu übergeben wird das Cookie nur 14 Tage leben, obwohl man es 21 Tage am leben halten möchte.
Die Cookie Klasse würde in Auszügen bei mir so aussehen
class cCookie
{
$intCookieLifetimeDays = cSystem::init()->getCookieLifetime();
public function getCookieLifetime()
{
return $this->intCookieLifetimeDays;
}
public function setCookieLifetime($intCookieLifetimeDays)
{
$this->intCookieLifetimeDays = $intCookieLifetimeDays
}
}
Der Defaultwert wird anfangs von meinem Gott-Singleton in das Objekt gesetzt. Das wird im Konstruktor erledigt. Danach hat das Objekt einen Defaultwert. Der kann jederzeit durch die Setter Methode angepasst werden.
Woher die Singleton Methode den Defaultwert hat ist irrelevant. Der Wert kann aus einer ini Datei kommen oder xml, csv, lma oder aus der Datenbank. Wenn der Wert aus der Datenbank kommen würde, dann könnte er sogar personalisiert sein. Sprich User A bekommt Cockies die 14 Tage halten User B bekommt Cookies für nur 2 Tage (da Verfassungsschützer :D).
Der Aufruf des Default Cookies ist dann:
new cCookie();
Dein Aufruf nach dem Prinzip dass alle Parameter bekannt sein müssen wäre:
new cCookie(14);
Wenn du jetzt irgendwann den Defaultwert ändern möchtest, darfst du das an x Stellen machen. Außer natürlich du kapselst den Aufruf in irgendeiner Form...also Depency Injection. Das hast du ja als erstes Vorgeschlagen.
Es gibt also etwas, dass den Aufruf kapselt:
function cookie()
{
return new cCookie(14);
}
Um jetzt eventuelle Sonderfälle zu behandeln muss das ganze noch über einen Parameter gesteuert werden:
function cookie(intCookieLifetime = 14)
{
return new cCookie(intCookieLifetime);
}
In meinem Beispiel existiert eine zusätzliche Funktion (könnte auch eine extra Klasse sein), welche sich nur um den Defaultwert kümmert.
Man könnte natürlich das ganze auch ohne D.I. erledigen:
new cCookie(getCookieLifetime());
Dann hat man jedoch wieder das Problem des Gott-Singletons bzw. verstreuen sich dann die Konfigurationselemente vielleicht im gesamten Sourcecode.
OOP hin, Martin Fowler her, du kannst es nennen wie du willst, aber ich stehe auf mein Gott-Singleton. Und wenn mein Chef irgendwann mal möchte, dass es anders heißt, dann werde ich deinen Chef dazu anstiften dein Depency Injektion Verwaltungsobjekt anders zu benennen.
Gruß
Finger wundgeschriebener
T-Rex