acetox94

Hallo liebe Community,

Ich hab da mal ne Frage.. Ich beschäftige mich momentan mit Softwaredesign und versuche nun Klassenpakete mithilfe meines neuen Wissens zu erstellen.. nur.. leider macht mir die Praxis einen Strich durch die Rechnung^^ Und zwar: Es geht um Objektabhängigkeiten. Diese sollte man ja wenn möglich als Parameter übergeben (Dependency Injection) und nich direkt in dem Objekt instanzieren, das die Abhängikeit benötigt. Ich weis nich, vllt hab ich mir da was zu stark in den Kopf gesetzt, aber ich stehe hier grad vor dem Problem, dass ich eine Instanz innerhalb einer Methode einer anderen Klasse erzeugen MUSS.
Jetzt meine Frage: Ist es generell "schlimm" wenn Objekte andere Klassen instanzieren? Wenn ja, was für möglichkeiten gibt es, solche Abhängigkeiten zu verringern? Sollte eine Klasse ihre Umgebung bzw. dessen abhängige Klassen kennen oder nicht?

Mfg Fips.

Mister Ad

nikosch

Das hast Du doch oben selbst beantwortet. Was Du dagegen nicht geschrieben hast, ist, welcher Zwang denn nun besteht, das tun zu „müssen“

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

acetox94

Der "Zwang" ist einen möglichst flexiblen und austauschbaren "Klassenpool" zu programmieren. Wenn Klassen sich kennen dürfen, warum gibt es dann sowas wie Dependency Injection?

nikosch

Nein, das ist nicht der Zwang.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

acetox94

Chriz

Nein, generell schlimm ist es nicht. Schliesslich ist dein MVC-Controller ja auch eine Klasse, instanziert aber moeglicherweise deine Models.

Mach doch mal ein Beispiel, wer was instanziert, warum und vor allem warum es alternativlos fuer dich erscheint.

__________________
"Nuschel ich?" - "Was?"

mermshaus

Es lässt sich theoretisch immer eine Factory injizieren. Aber ein konkretes Beispiel fände ich auch gut.

__________________
Blog | Buch | Kaloa

xm22

Die Klassen selber sollen sich ja nicht kennen müssen. Lediglich (Im Idealfall) die dazugehörigen Interfaces. Das ist ja gerade der Vorteil von Dependency Injection.

litterauspirna

Ich denke auch hier fehlt der konkrete Anwendungsfall.

Es gibt Fälle wo es Sinn macht in einer Klasse eine Instanz auf ein anderes Objekt zu bilden, wirklich einfallen tut mir da auch nur erst mal ein Model und einen ModelWrapper in einen Controller zu instanzieren. Da Models und ModelWrapper in der Regel immer Controllerabhängig sind macht das hier sogar Sinn das der Controller seine Models und ModelWrapper kennt, warum auch nicht.

Ansonsten bzw. in den meisten Fällen sollte aber gegen Interfaces programmiert werden um eine gewisse lose Koppelung von der Anwendung zu gewährleisten.

Gruß Litter

__________________
Aus dem Dynamo Lande kommen wir. Trinken immer reichlich kühles Bier. Und dann sind wir alle voll, die Stimmung ist so toll. Aus dem Dynamo Lande kommen wir.
http://www.lit-web.de

acetox94

exakt. Gut. Ich geb mal ein Beispiel: Ich abeite momentan an einem Dateisystem-Paket. Dieses enthählt (unter anderem^^) 2 Klassen: File und Dir. Die Klasse Dir enthählt die Methode getChildren(), die alle Ordner und Datein innerhalb des Ordners als Instanz zurückgeben soll (Also Bei Datei ein Objekt der Klasse File und bei einem Ordner ein Objekt der Klasse Dir). Die Funktion getChildren in der Klasse Dir muss jez aber natürlich den Namen der Klasse File wissen, hat jedoch eigentlich garnix mit der Klasse zu tun. Würde ich jetzt z.B. eine Klasse ConfigFile anlegen und würde wollen, dass die Methode getChildren() bei einer Konfigurationsdatei eine Instanz der Klasse ConfigFile zurückgeben soll, müsste die Funktion auch deren Klassennamen wissen. Das is natürlich doof :/

Mfg Fips.