nicht angemeldet
Hey!
Da würde ich jetzt erstmal ganz simpel sagen: Na und?
Und ich: "Und was?!"
Und zweitens würde ich mich fragen, was das denn für eine grausame Funktion ist?
Die ist aus mehreren Gründen grausam:
Ah, na schauen wir doch mal...
Erstens hat sie eine mangelhafte Signatur: Optionale Elemente gehören ans Ende der Parameterliste, und offenbar ist das Objekt optional.
Nein, ist es nicht. Das Objekt (bzw. dessen Klassenname und die Parameter sind Pflicht).
Zweitens: Wieso verlangt die Funktion ein Objekt, dass sie hinterher nicht braucht? Wenn man das offenbar anhand des übergebenen Parameters ermitteln kann, warum wird das nicht außerhalb der Funktion ermittelt?
Weil die Funktion ein Cache für benötigte Objekte anlegt. Ob die Objekte später aber auch tatsächlich benötigt werden, regelt eine externe Controller-Klasse.
Wenn die Funktion die Objekte herstellt, erfüllt sie eine weitere Aufgabe zusätzlich, die ihr nicht zusteht.
Ja, das überlasse ich dann wohl der Controller-Klasse. Ändert aber erstmal nichts an meinem "Problem".
Und alle haben sie unterschiedlich lange Parameterlisten des Konstruktors (was auch wieder sehr fragwürdig ist im Hinblick auf Vererbung und Selbstähnlichkeit, aber sofern die Objekte zumindest alle dasselbe Interface gegenüber der Funktion implementieren, kann das mit den notwendigen Unterschieden der Unterklassen durchaus begründet sein).
Sie "extenden" alle die selbe Klasse.
Deine Beschreibung deutet an, dass die Klassenstruktur sowieso nicht optimal ist.
Controller A sammelt Daten über Model B (welche Daten) und Daten über Model B (welche Bedingungen). Danach vergleicht A B mit C und liefert die Schnittmenge. Die Frage ist halt nur, warum ich die Ergebnisse von, in dem Fall, B instanzieren sollte bevor sie in der Schnittmenge landen? Was ist an der Klassenstruktur nicht optimal?
Du hast außerdem außer deinem Gefühl für Unschönheit noch kein Argument GEGEN die Instanziierung gebracht. Das einzige Argument, das mir einfiele, wäre Performance - und das dann gültige Gegenargument ist: Tu nix im Konstruktor, außer die Parameter im Objekt lokal abzuspeichern.
Ja deshalb hätte ich auch eigentlich eher gern die Parameter im Konstruktor. Allerdings kann ich "zur Not" natürlich auch in der externen Logik dafür sorgen, dass die Instanzierung einer "Konvention" erfolgt. Z.B. Objekt instanzieren, dann eine Funktion der Elternklasse aufrufen um die Parameter zu initialisieren.
Das einzige dann noch verbleibende Gegenargument wäre Speicherverbrauch. Um den kommst du aber bei keiner Lösung drum herum, denn ein Array mit den Konstruktorparametern kostet auch Speicher, ebenso wie das Callable.
Schon 2 "einzige"? ;)
Aber ja, am Ende braucht ein Objekt natürlich auch mehr Speicher als ein paar Strings (Klassenname+Parameter) in einem Array.
Das ist genauso schlecht. Deine Funktion hat nicht die Aufgabe, Objekte zu bauen.
Richtig, sie soll sie nur cachen. Bzw. nur deren Namen und Parameter.