nicht angemeldet
Moin!
Es klingt ein bisschen, als ob du dich angegriffen fühlst.
Selbstverständlich wenn erstmal so eine Eröffnung (inklusive Ausführung) kommt
"Da würde ich jetzt erstmal ganz simpel sagen: Na und?
Und zweitens würde ich mich fragen, was das denn für eine grausame Funktion ist?"
Was als Argument gemeint war, "es" einfach so zu tun und nicht verzweifelt nach einer Instanzvermeidungsstrategie zu suchen. Es ist auch der Versuch, mehr Informationen herauszukitzeln, denn wie auch dedlfix immer klarer erkennt: Wir haben es hier mit einem klassischen X-Y-Problem zu tun: Du hast Problem X und denkst, es wird von Y gelöst, und fragst nun nach Hilfe zu Y, anstatt das Problem X zu beschreiben.
Ich glaube, ich habe im Laufe der Zeit in Foren ganz gute Antennen dafür entwickelt, ob jemand nach seinem wirklichen Problem fragt, oder ob das wirkliche Problem sich noch eine Ebene dahinter verbirgt.
Wenn es bislang nur um "rohe" Klassen ging und keine einzige Zeile Code und auch nicht der Zusammenhang bekannt sind, so einzusteigen, hat schon was für sich.
Das wäre aus meiner Sicht noch ein Grund weniger, sich persönlich angegriffen zu fühlen - was auch nicht meine Absicht ist und war.
Genau. Wie kann man also erstmal reinpoltern ohne zu wissen um was es geht aber direkt alles in Grund und Boden stampfen? Nein danke, darauf kann ich dann auch verzichten. Ich werde mir Svens Vorschläge/Hinweise anschauen aber hier hat sich der thread für mich erstmal erledigt.
Du hast gefragt, ob's zu deiner Lösung noch was besseres gibt.
Meine Antwort enthielt dazu mindestens zwei konkrete Lösungsangebote: 1. So lassen ("na und"), 2. Closures. Und den Versuch, dem Problem auf den Grund zu gehen.
Und wann habe ich gesagt, dass ich das so mache? Bis jetzt waren alles nur Überlegungen wie ich es umsetzen _könnte_.
Deine Schilderung klang so, als wäre konkreter Code dahinter, den du nicht nennen willst.
Das kann man erst sagen, wenn man die Hintergründe kennt. Versuch mal bitte etwas konkreter und nicht so abstrakt zu beschreiben, was du vorhast.
Da gibt es nichts zu beschreiben weil ich (fast) nur mit rohen Klassen zum testen arbeite.
Eine Funktion sammelt Informationen über verschiedene Model. Die Model erweitern alle eine Elternklasse, was aber nicht bedeutet, dass sie zwangsläufig die selben Konstruktoren besitzen müssen. Eine Andere Funktion bildet eine Schnittmenge mit den tatsächlich benötigten Models und initialisiert die entsprechenden Klassen.
An dieser Stelle sagt mir meine Erfahrung auch schon wieder: "Vorsicht, 'Code smell'". Models wie ich sie verstehe haben in der Regel nichts miteinander gemeinsam, so dass Vererbung von einer zentralen Klasse nicht notwendig sein sollte.
Wenn wider Erwarten dafür doch starke Argumente vorliegen, würde ich untersuchen, ob man dem Problem besser mit Komposition statt Vererbung beikommen kann.
"Cheeseburger" braucht zum Beispiel die Model "Cheese('gauda', '1 scheibe')" und "Burger('weizenbrötchen', '1 formfleisch', '2 scheiben gurken', 'zwiebeln')".
"Hamburger" braucht nur "Burger".Meine Funktion sammelt also "Cheese" und "Burger" und für welchen Burger sie gebraucht werden - übergeben von einer Controller-Funktion.
Z.B. Cheeseburger: Cheese('gauda', '1 scheibe'), Burger('weizenbrötchen', '1 formfleisch' /* , ..*/)
DoppelWopper: Cheese('gauda', '2 scheiben'), Burger('weizenbrötchen', '2 formfleisch', '4 scheiben gurken')
Also hast du ein Objekt-Konstruktionsproblem? Auch dafür gibts bereits schöne Lösungen, nur würde man vermutlich nicht Burger und Käse parallel in eine Funktion tun, um beide aufeinander zu legen oder den Käse wegzulassen, sondern man würde den Burger mit oder ohne den Käse bauen, und dann nur den in die Funktion tun.
Dein Suchstichwort für Google hierfür heißt "Dependency Injection".
Eine andere Controller-Funktion sucht nun alle Model die für einen bestimmten Burger gebraucht werden. Also zu Cheeseburgern den Cheese und zu Hamburgern nicht. Cheese wird also "aussortiert" und nicht erst ausgepackt und drauf gelegt und nach dem Vergleich wieder runter genommen. Speicher hin oder her (wenn sich nicht mal der Experte sicher ist), das ist einfach unlogisch.
Da hast du vollkommen recht, dass man Objekte nicht erzeugen sollte, die man garantiert nicht braucht. Und schon sind wir wieder am Anfang der Diskussion und meiner Analyse: Wenn die Funktion das Objekt zwingend, weil als ersten Parameter mit nachfolgenden Pflichtparametern, verlangt, es dann aber wegwirft, stimmt was an der Parameterliste oder an der Funktion nicht.
Leider bin ich dem wirklichen Problem X immer noch nicht näher gekommen, weil von dir dazu keine neuen Informationen kommen. Von "Objekte und Funktion" über "Caching" über "MVC-Modelschicht" bis zu "Dependency Injection" war jetzt schon alles dabei - und damit wurde vermutlich schon gut die Hälfte der typischen Konstruktionen genannt, und jede einzelne von denen hat ihre unterschiedliche, typische Lösung, die aber nie auf eine der anderen Probleme passt - und keine erzeugt Objekte, die dann wieder weggeworfen werden.
- Sven Rautenberg