nicht angemeldet
Moin!
Also ich finde deine Antwort nicht gerade nett.
Ich habe das System kritisiert, nicht dich.
Zumal sie aus vielen Vorurteilen besteht.
Ich kenne nur die Erzähölung aus deinem Posting. Erzähl mehr, und wir können in eine fruchtbare Diskussion einsteigen.
Ich würde liebend gerne schreiben, dass mein System nicht abhängig von dem Singleton ist. Da dort jedoch ein Array für die Datenbank Verbindung hinterlegt ist... :D. Es ist jetzt aber nicht so das mein System mit dem Singleton "gepflastert" ist.
Ein einziges Singleton reicht schon, damit das Leben nicht mehr so schön ist.
Dein Post lässt mich jedoch in einem falschen Licht stehen.
Dein Post beschreibt, was getan wurde. Ich kritisiere, was getan wurde. Wenn du dafür verantwortlich bist, darfst du dir die Kritik durchlesen, drüber nachdenken, und zu Schlüssen kommen. Ich schreibe dir nicht vor, was das Ergebnis sein soll, aber ich diskutiere gerne mit dir, warum deine Schlüsse derzeit gewisse Dinge, die ich für essentiell halte, nicht ausreichend berücksichtigen.
Wenn ich mir das so durchlese muss ich wieder an meinen Kollegen denken, der meint er kann OOP nur weil er das Wort "class" schreiben kann. Am Ende kommt strukturelle Programmierung heraus unterstützt mit Objekt Methoden (wobei man da gleich Funktionen nehmen könnte).
Hast du den Verdacht, dass dein eigener Wissensstand auch nur auf diesem Niveau basiert? Dann sollten wir diskutieren, warum du gewisse Dinge so getan hast, und ich zeige dir gerne die Folgen auf, die daraus resultieren, an die du bislang noch nicht gedacht hast. Möglich, dass die für dich irrelevant sind. Aber fachlicher Austausch hat noch niemanden dümmer gemacht. :)
Auf der anderen Seite hast du mich extrem Neugierig gemacht. Nehmen wir mal an es gibt einen Cookie. Der hat eine Lebensdauer von 14 Tage. Die 14 Tage sind jedoch nur Default. Es gibt eine Klasse cCookie welche das setzen des Cookies übernimmt. Über eine Methode bzw. Eigenschaft kann man die Lebensdauer einstellen. Wenn keine Lebensdauer eingestellt wurde, sollen die 14 Tage genommen werden.
Die Lebensdauer eines Cookies ist nichts, was essentiell als Wissen in diese Cookie-Klasse gehört. Die Cookie-Klasse sollte explizit einen vom Programmierer anzugebenden Wert fordern. Der Programmierer muss also "14 Tage" als Zeitdauer hineingeben.
Damit transformiert sich die Frage zu: Wie konfiguriere ich Werte? Und eventuelle Default-Werte?
Damit verbunden dann die Frage: Was macht einen Wert so besonders, dass er Default-Wert sein soll? Für welche Dinge ist es denn überhaupt sinnvoll, alternativ zu einem explizit abweichenden Wert ein Default-Verhalten zu implementieren? Kann man nicht einfach zwingend fordern, dass der Programmierer immer einen Wert konfiguriert - und der konfigurierte Wert ist dann der finale Wert? Das macht die Dinge einfacher, weil kein geheimnisvoller Default-Wert ins Spiel kommt, sondern von vorn bis hinten nur ein einziger Wert relevant ist.
Denn wenn du mit zwei Werten arbeitest, dem "normal konfigurierten" und dem "Default", dann wäre die nächste Frage: Wenn ich den normalen Wert konfigurieren kann, wie konfiguriere ich dann den Default-Wert?
Und an der Stelle schließt sich der Kreis, und das Sonderbehandeln eines Default-Werts wird sinnlos oder besonders aufwendig. Man kann nicht ZWEI Werte für einen Parameter zur selben Zeit haben, wirksam werden kann immer nur ein einziger.
Ich mag auch eigene Funktionen/Methoden mit optionalen Parametern nicht wirklich. Wozu sollen die gut sein? In der Regel rufe ich die Funktion immer mit dem vollen Satz an Parametern auf, die alle durch Variablen befüllt werden, die anderswo herkommen. Ich liefere also immer Werte, so dass kein Parameter jemals "optional" ist. Ich kann mir also sparen, den Parameter optional zu machen, weil dieser Anwendungsfall nicht auftritt, und ich spare mir, diesen Sonderfall extra zu testen.
Ich würde das über das "Gott-Singleton" lösen. Wie würdest du es machen? Ich bin enorm gespannt!!!
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.
Wenn ein Wert nicht definiert ist, existiert er nicht. Die Klasse fügt nicht aufgrund ihres eigenen Programmcodes einen x-beliebigen Konfigurationswert hinzu, der als Default wirkt.
Daraus folgt, dass man sämtliche Werte, die in der Applikation konfiguriert werden müssen, in der Konfigurationsdatei stehen hat. Damit wird dann auch offensichtlich, von welchen Werten die Applikation in der jeweiligen Umgebung abhängt.
Davon unabhängig ist es natürlich eine andere Sache, wenn man beispielsweise Pauschal- und Detailkonfigurationen handhaben will:
cookie.lifetime = 14d
cookie.lifetime.cart = 365d
;cookie.lifetime.voting = ?
Resultiert in 14 Tagen Cookiegültigkeit für alle Module, der Warenkorb kriegt ein Jahr, und das Voting könnte abweichend konfiguriert sein, ist es aber nicht - also 14 Tage.
Das Abfragen eines Detailwertes greift also immer auf den Pauschalwert zurück, der zwingend definiert sein muss. Dieser Defaultwert ist aber ebenfalls konfiguriert, er steht nicht irgendwo im Code versteckt. Denn eine Klasse sollte sich immer nur aus einem Grund ändern (Single Responsibility Principle), und wenn das Ändern der gewünschten Default-Cookie-Lifetime dieser Grund ist, wären anderen Gründe, wie z.B. Abändern der Konfigurationsspeicherung etc., überzählige und damit unzulässige Gründe.
- Sven Rautenberg