Gibt es eine alternative zu bastard-injection? (AKA poor man ' s injection via default Konstruktor)

Ich am häufigsten bin versucht zu verwenden, "bastard-Injektion" in ein paar Fällen. Wenn ich ein "richtiges" dependency injection constructor:

public class ThingMaker {
    ...
    public ThingMaker(IThingSource source){
        _source = source;
    }

Dann aber für Klassen, die ich bin, die beabsichtigen als öffentlichen APIs (Klassen, anderen Entwicklungsteams verbrauchen), ich finde nie eine bessere Möglichkeit, als zu schreiben, ein Standard - "bastard" - Konstruktor mit den meisten-wahrscheinlich brauchte Abhängigkeit:

    public ThingMaker() : this(new DefaultThingSource()) {} 
    ...
}

Der offensichtliche Nachteil hier ist, dass diese erstellt eine statische Abhängigkeit von DefaultThingSource; im Idealfall gäbe es keine solche Abhängigkeit, und die Verbraucher würden immer Spritzen, was IThingSource Sie wollten. Dies ist jedoch zu schwer zu verwenden; wollen die Verbraucher von neuen ein ThingMaker und an die Arbeit machen, Dinge, die dann Monate später injizieren etwas anderes, wenn die Notwendigkeit entsteht. Dies lässt nur ein paar Optionen meiner Meinung nach:

Weglassen der bastard Konstruktor; macht der Verbraucher von ThingMaker zu verstehen IThingSource, zu verstehen, wie ThingMaker interagiert mit IThingSource, finden oder schreiben Sie eine konkrete Klasse, und dann Spritzen Sie eine Instanz in Ihrem Konstruktor aufrufen.
Weglassen der bastard Konstruktor und eine separate Fabrik -, container -, oder andere bootstrapping-Klasse/Methode; irgendwie machen die Verbraucher verstehen, dass Sie nicht brauchen, um zu schreiben Ihre eigenen IThingSource; macht der Verbraucher von ThingMaker zu finden und zu verstehen, die Fabrik oder bootstrapper und verwenden Sie es.
Halten die bastard-Konstruktor, so dass der Verbraucher zu "neu" ein Objekt aus und führen Sie mit ihm, und der Umgang mit dem optionalen statischen Abhängigkeit von DefaultThingSource.

Boy, #3 hat sicher scheint attraktiv. Gibt es eine andere, bessere option? #1 oder #2 einfach nicht scheinen, es lohnt sich.

Warum ist die Abhängigkeit von DefaultThingSource schlimmer als die Abhängigkeit von IThingSource? Gehen Sie mit #3.
Da DefaultThingSource ist ein potenziell sehr spezifische Umsetzung, mit Abhängigkeit von einem externen system in einer anderen assembly, die auch überholt in ein paar Monaten; IThingSource ist in der stets korrekt und nie gebunden an eine spezifische Implementierung.
Natürlich weiß ich nicht, wie Komplex DefaultThingSource ist. Aber ich würde Wetten, dass wenn Sie die Dinge einfach halten und es gut design, in Wirklichkeit werden Sie feststellen, dass Ihr code wird nicht veraltet sein, so schnell wie Sie Angst-mit Sicherheit nicht schnell genug, um zu rechtfertigen, all diese Herzschmerz.
Das ist das problem mit guten dependency-inversion - kann es sein, flexibler und besser zu gestalten, aber es ist nicht so einfach für einen neuen programmer zu verwenden.
Sie können auch wollen, um einen Blick auf diesen Artikel: lostechies.com/jimmybogard/2009/07/03/...
Beachten Sie auch, dass diese Praxis ist auch bekannt als "Poor Man' s Dependency Injection".
DefaultthingSource ist ... überholt in ein paar Monaten" - Dann ist es ein sehr schlechter Kandidat für eine "Standard" - in einem öffentlichen Aufruf. Ich vote für #2
Deshalb habe ich "möglicherweise" veraltet-wir wissen nicht, wie Sie sich entwickeln wird, in Verwendung. Wir hoffen, dass unsere Verbraucher finden Sie alle Arten von wertvollen Möglichkeiten, unsere software zu nutzen.

InformationsquelleAutor Patrick Szalapski | 2011-07-18

.net c#constructor dependency-injection oop

60

Soweit ich das verstanden habe, diese Frage bezieht sich auf, wie setzen Sie eine lose gekoppelte API mit einigen passenden Standardeinstellungen. In diesem Fall haben Sie möglicherweise eine gute Lokalen Standard -, in welchem Fall der Abhängigkeit angesehen werden können, werden als optional. Eine Möglichkeit für den Umgang mit optionale Abhängigkeiten ist die Verwendung Eigenschaft Injektion statt Constructor Injection - in der Tat, das ist die Art von poster-Szenario für die Property-Injection.

Jedoch die Reale Gefahr des Bastard-Injektion ist, wenn der Standardwert ist ein Ausländischen Default, denn das würde bedeuten, dass der Standard-Konstruktor entlang zieht sich eine unerwünschte Kopplung an die Montage der Umsetzung der Vorgabe. Wie verstehe ich diese Frage, jedoch ist der beabsichtigte Standard würde entstehen, in der gleichen assembly, in dem Fall sehe ich keine Besondere Gefahr.

In jedem Fall könnte man auch überlegen, eine Fassade, wie beschrieben, in einer meiner früheren Antworten: Abhängigkeit Injizieren (DI) "freundliche" Bibliothek

BTW, das hier verwendete Terminologie basiert auf der pattern language von mein Buch.
- +1 DI-friendly library Antwort ist ein absolutes muss, Lesen Sie in diesem Raum und wird Ihnen ermöglichen, zu denken, durch dieses Zeug aus der ersten Prinzipien.
- Die Fassade ist eine wirklich gute Idee als gut.
- Guter Gedanke, über den Unterschied zwischen lokalen Vorgaben und ausländische Standardwerte. In diesem Fall, es ist in der Tat ein lokaler Standard, wenn auch eine, der Verbraucher kann auch einen Grund haben, zu überschreiben. In diesem Fall bietet zwei Konstruktoren Hinweise auf "verwenden Sie die Standard-oder injizieren Ihre eigenen" most einfach. Mit nur einem default-Konstruktor mit der Eigenschaft Injektion tut nicht genug, um Werbung für die injizierbare Abhängigkeit. Sind Sie damit einverstanden?
- Ich bin damit einverstanden, dass überladene Konstruktoren sind in Ordnung, in dieser situation. Ich bin nicht einverstanden, dass Immobilien, die Injektion tut nicht genug, um anzukündigen, dass Benutzer außer Kraft setzen können, die Abhängigkeit, wie es ist ein bekanntes Muster, aber ich gebe die überladene Konstruktoren sind geringfügig mehr "in your face":)
- Nicht zu empfehlen @MarkSeemann Buch genug für all diese Fragen von DI und IoC
- in Bezug auf die Fassade, ich habe Probleme bei der Vereinbarkeit von der Idee, dass alles was ich getan habe, ist bewegen Sie den bastard Injektion zu einer anderen Klasse. Was ist Ihre Meinung zu deklarieren, die Standard-Abhängigkeit in der config-Datei und laden Sie es über late-binding?
- Zwingen Konfigurationsdatei-Einstellungen auf die Benutzer der library ist nicht besonders freundlich Ansatz. Es sperrt clients für die Verwendung der system-Konfiguration, die ist zu unflexibel. Was, wenn Sie wollen, um Last-config-Werten aus einer Datenbank statt aus einer config-Datei? Was ist, wenn Sie variieren möchten-Konfiguration die Werte in unit-tests? Was, wenn Sie wollen, um die Konfiguration Wert konfigurierbar über das UI? ...FWIW, ich habe erweitert, auf der DI freundlich Bibliothek Empfehlungen hier, darunter mehr code-Beispiele.
- Danke, @MarkSeemann. Das war genau das, was ich suchte.
InformationsquelleAutor Mark Seemann
32

Meine trade-off ist ein spin auf @BrokenGlass:

1) der Einzige Konstruktor ist parametrisierten Konstruktor

2) Verwenden Sie die factory-Methode zum erstellen einer ThingMaker und pass auf, dass die Standard-Quelle.
```
public class ThingMaker {
  public ThingMaker(IThingSource source){
    _source = source;
  }

  public static ThingMaker CreateDefault() {
    return new ThingMaker(new DefaultThingSource());
  }
}
```
Offensichtlich nicht zu beseitigen, Ihre Abhängigkeit, aber es macht es übersichtlicher für mich, dass dieses Objekt mit Abhängigkeiten, die von einem Anrufer kann tief Tauchen Sie ein in wenn Sie interessiert. Sie können machen, dass die factory-Methode noch deutlicher, wenn Sie mögen (CreateThingMakerWithDefaultThingsource), ob das hilft, mit Verständnis. Ich bevorzuge, dies zu überschreiben der IThingSource factory-Methode, da Sie es weiterhin bevorzugen Komposition. Sie können auch hinzufügen einer neuen Fabrik-Methode, wenn die DefaultThingSource ist veraltet und haben einen klaren Weg zu finden, alle den code mit dem DefaultThingSource und zu markieren, die aktualisiert werden.

Sie überdachte die Möglichkeiten, die in Ihrer Frage. Factory-Klasse, die anderswo für Komfort oder einigen Komfort innerhalb der Klasse selbst. Die einzige andere unschöne Möglichkeit wäre die Reflexion-basiert, ausblenden der Abhängigkeit noch weiter.
- Ich verstehe immer noch nicht warum dies besser ist als die default-Konstruktor--es hat all die Nachteile, die mit keinen zusätzlichen nutzen; es macht die Abhängigkeit mehr verschleiert zu wer Lesen den code.
- Meiner Meinung nach macht es die Abhängigkeit deutlicher als mit dem Standard-Konstruktor. Die Art und Weise der Klasse entwickelt, scheint darauf hinzudeuten, dass die Abhängigkeit ist wichtig (es ist der Injektion in den Konstruktor), so würde ich das machen, dass explizite. Der default-Konstruktor sagt mir: "Mach dir keine sorgen über diese Abhängigkeit habe ich nur erstellt einen zusätzlichen Konstruktor für die Prüfung oder einer einmaligen Fall". Die factory-Methode sagt mir, "Es ist eine Abhängigkeit, die bewusst zu sein, aber hier ist die wahrscheinlichste Umsetzung, die Sie suchen"
- Sollte dies nicht sein "CreateDefault" mit einem Kapital C?
- Diese Lösung macht nicht klar, wie diese Klasse verwendet werden soll. Die erste Sache, die Sie betrachten, wenn die Verwendung einer Klasse für die erste Zeit, ist der Konstruktoren, wenn ich sehen nur einen Konstruktor gehe ich davon aus, dass ich MUSS eine Instanz von IThingSource um ThingMaker. Die Chancen sind, dass, wenn ich ein Benutzer einer solchen Klasse wäre ich nie entdeckt hatte, die CreateDefault Methode.
- Ich bin noch nicht davon überzeugt, Steve. Während die Anzahl der upvotes könnte darauf hinweisen, dass ich falsch Liege, ich glaube nicht, dass ein default-Konstruktor heißt "habe ich nur erstellt einen zusätzlichen Konstruktor für die Prüfung oder ein einmaliger Fall." Stattdessen, ich denke, es bedeutet, "Verwenden der Standard-oder injizieren Ihre eigenen." Sie sagte auch, dass Sie denken, dass Sie den Standardkonstruktor bedeutet "Mach dir keine sorgen über diese Abhängigkeit" - und das Stimme ich mit. Sie können den Standard-Konstruktor, wenn Sie nicht wollen, sorgen sich die anderen.
- Fair genug. Dies ist lediglich eine alternative, wenn Sie wollen, zu betonen, die Abhängigkeit ein bisschen mehr. Es gibt immer einen trade-off in diese Entscheidungen, und es ist wirklich eine Frage, wo wollen Sie Ihre Schwerpunkte. Wenn die DefaultThingSource ist die primäre option für die meisten Anrufer dann würde ich ermutigen, es auch in der default-Konstruktor. Wenn Sie möchten, dass der Anrufer zu berücksichtigen, die Ihren eigenen IThingSource dann denke ich, das ist ein akzeptabler Mittelweg. Wenn Sie möchten, um den Benutzer zu zwingen, um die Versorgung ein IThingSource dann starte ich lehnte sich in Richtung factory-Klassen.
InformationsquelleAutor Steve Jackson
8

Eine alternative ist es, eine die factory-Methode CreateThingSource() in Ihrem ThingMaker Klasse schafft, dass die Abhängigkeit für Sie.

Zum testen oder wenn Sie brauchen eine andere Art von IThingSource man müsste dann erstellen Sie eine Unterklasse von ThingMaker und überschreiben CreateThingSource() zur Rückgabe der konkreten Art Sie wollen. Offensichtlich ist dieser Ansatz nur lohnt, wenn man hauptsächlich in der Lage sein müssen, um zu injizieren, die in Abhängigkeit zum testen, aber für die meisten/alle anderen Zwecke benötigen keine andere IThingSource
- Ich dachte das, aber es hat alle Nachteile der bastard option Konstruktor mit keiner der Vorteile! Richtig?
- Ich Stimme mit Patrick ' s Kommentar hier.
- Wie vereinbart, für die meisten Teil - ich verwende die default-Konstruktor zum erstellen des "default" - Abhängigkeiten, die mich und sehe nichts falsch mit ihm. Dies ist anders, weil es erlauben würde, Sie nicht habend, haben die Abhängigkeit in irgendeinem Konstruktor - auf diese Weise würden Sie vermeiden eine andere, wie Sie es nennen "bastard-Konstruktor", so dass die öffentliche Schnittstelle, die einfacher zu analysieren. Dies macht nur dann Sinn machen, wenn die änderung der Abhängigkeit ist nur relevant für die Testbarkeit der Klasse.
InformationsquelleAutor BrokenGlass
6

Ich vote für die #3. Sie werde machen Ihrem Leben-und das Leben anderer Entwickler,--leichter.
- Können Sie erklären, wie? Welche Probleme versucht der Dritte Ansatz zu vermeiden?
- #1 erfordert zusätzliche Arbeit für den Verbraucher. #2 erfordert zusätzliche Arbeit, auf die sowohl die Verbraucher und Patrick. Weder #1 noch #2 genügend Vorteile überwiegen die wahrgenommenen Nachteil, dass eine Abhängigkeit von DefaultThingSource.
- Diejenigen, die bereits in der Frage genannten.
- Ich denke, dass @Mark Seemann Antwort am nächsten kommt, was einen guten Entwurf, während das Leben in der realen Welt, aber diese Antwort ist einfach und auch gut. 🙂
InformationsquelleAutor Fernando
6

Wenn Sie ein "Standard" - Abhängigkeit, auch bekannt als "Poor Man' s Dependency Injection, dann haben Sie zu initialisieren und "Draht -" die Abhängigkeit irgendwo.

Behalte ich die zwei Konstruktoren haben aber eine Fabrik nur für die Initialisierung.
```
public class ThingMaker
{
    private IThingSource _source;

    public ThingMaker(IThingSource source)
    {
        _source = source;
    }

    public ThingMaker() : this(ThingFactory.Current.CreateThingSource())
    {
    }
}
```
Nun in der Fabrik erstellen Sie die Standard-Instanz und lassen die Methode overrided:
```
public class ThingFactory
{
    public virtual IThingSource CreateThingSource()
    {
        return new DefaultThingSource();
    }
}
```
Update:

, Warum mit zwei Konstruktoren:
Zwei Konstruktoren zeigen deutlich, wie die Klasse verwendet werden soll. Der parameterlose Konstruktor Staaten: erstellen Sie einfach eine Instanz und der Klasse führen alle it-Aufgaben. Nun der zweite Konstruktor besagt, dass die Klasse hängt von IThingSource und bietet eine Möglichkeit, eine Umsetzung anders als die Voreinstellung.

Warum eine Fabrik:
1 - Disziplin: Erstellen von neuen Instanzen sollten nicht Teil der Aufgaben dieser Klasse eine factory-Klasse sinnvoller ist.
2 - TROCKEN: stellen Sie sich vor, dass in der gleichen API-andere Klassen auch davon abhängen, IThingSource und das gleiche tun. Überschreiben Sie einmal die factory-Methode zurückgeben IThingSource und alle Klassen in der API automatisch starten, verwenden Sie die neue Instanz.

Sehe ich nicht ein problem in der Kupplung ThingMaker um eine default-Implementierung von IThingSource solange diese Umsetzung sinnvoll, um die API als ganzes, und auch Sie bieten Möglichkeiten zum überschreiben diese Abhängigkeit für die Prüfung und Erweiterung der Zwecke.
- Warum eine Fabrik haben, dann? Nur die Logik in der ThingMaker default-Konstruktor.
- Dies ist notwendig wenn Sie unbedingt eine öffentliche ctor. Wenn Sie nicht in diesem Boot, das ist eine schlechte Idee. Können Sie machen, dass Sie klare Antworten oder hätte ich das Gefühl, es sollte downvoted auf der Grundlage, dass es nicht alles hinzufügen, was die andere Antwort nicht bereits tun und ist deutlich schlechter Umsetzung gegeben, dass Sie nicht entfernen Sie das Kupplung-Problem.
- Bartelink: habe ich aktualisiert meine Antwort zu erklären, die design-Entscheidungen.
- "Erstellen von neuen Instanzen [von selbst] sollte nicht ein Teil der Verantwortung dieser Klasse." Wirklich? Könnte man nicht sagen, dass etwa jeder Klasse und jedem angelegt? Ich denke, dass factory-Methoden/Klassen haben Ihren Platz, aber ich kann doch nicht immer verwenden Sie für alles.
- Es ist eine Frage der Präferenz. Ich persönlich versuche zu isolieren, die Schaffung neuer Instanzen von sinnvollen Klassen nur einen Platz in meinem APIs, damit der Fabrik-Nutzung. Auch von der Verwendung einer Fabrik die Standard-IThingSource kann leicht geändert werden, die von einem zentralen Ort. Wie ich schon sagte persönliche Vorlieben.
- Um deutlich zu machen, werden Ihre änderungen nicht übermannt mich. Vermisste ich ein wichtiges Wort in meinem ursprünglichen Kommentar -- Wenn Sie unbedingt einen öffentlichen parameterlosen constructor (für die Serialisierung oder weil die ein Attribut), dann fein. In allen anderen Fällen, der bastard injector ist ganz schlechte Nachricht. Wenn Sie das klarstellen/erklären, ich upvote, sonst +0/meh/Ihre Antwort sieht auf einen Blick, als ob es befürwortete, schlechte Erfahrungen, aber ich würde downvote, weil es ist eine wichtige Technik in der it. Dies ist über das entfernen von redundanten statische Referenzen auf die max degree möglich.
- Bartelink: damit Anrufer zum instanziieren der ThingMaker Klasse und verwenden Sie die Standard-Abhängigkeit für IThingSource, das ist eine Funktionalität, die der Autor der Frage will, müssen Sie einen parameterlosen Konstruktor hat, ist entweder das, oder irgendeine andere der weniger klare Lösungen vorgeschlagen, wie die statische CreateDefault Methode, die halte ich nicht für angemessen. Vielen Dank für Ihr feedback.
- OK. Ich habe re-Lesen Sie die Frage und akzeptieren, dass dies ist eine saubere impl #3. Ich nicht einverstanden mit #3 außer Ionen meinem zitierten Fällen (Attribute und Serialisierung, wo ein pub paramless ctor ist reqd) also das würde normalerweise bekommen Sie einen upvote von mir, aber die Debatte und der Tatsache, du bist etwas hinzufügen einen Hauch anders verdient ein upvote.
InformationsquelleAutor JCallico
2

Sind Sie unzufrieden mit der OO-Verunreinigung dieser Abhängigkeit, aber Sie nicht wirklich sagen, was für Probleme es letztlich bewirkt.
- Ist ThingMaker mit DefaultThingSource in einer Weise, die nicht den IThingSource? Nein.
- Könnte es eine Zeit kommen, wo Sie gezwungen wäre, in den Ruhestand den parameterlosen Konstruktor? Da Sie in der Lage, eine default-Implementierung zu diesem Zeitpunkt unwahrscheinlich.
Ich denke, das größte problem hier ist die Wahl des namens, nicht, ob die Technik zu nutzen.
- Ich weiß nicht, wie die statische Abhängigkeit DefaultThingSource.
- Warum tun Sie nicht, wie die Abhängigkeit?
- Ich Stimme dir zu, David. Außer, dass ich würde nicht den Ausdruck "OO Unreinheit", denn es gibt nichts unreines über die Abhängigkeit. Es ist einfach ein Urteil Anruf als zu haben oder nicht. Ich bin damit einverstanden, dass es ist nicht ein problem.
- B: ich nehme an, es ist nicht gefallen, weil, sobald ein Benutzer beginnt, mit AwesomeNewThing, es wird immer noch eine veraltete, ungenutzte Abhängigkeit von DefaultThingSource.
- Das Abhängigkeit ist nicht öffentlich bekannt und können geändert werden, ohne Unterbrechung der Benutzer.
InformationsquelleAutor Amy B
2

Die Beispiele, die in der Regel mit dieser Art von Injektion sind oft extrem simplisitic: "in der default-Konstruktor für die Klasse B, rufen Sie einen überladenen Konstruktor mit new A() und werden auf Ihrem Weg!"

Die Realität ist, dass die Abhängigkeiten sind oft äußerst Komplex zu konstruieren. Was zum Beispiel, wenn B braucht eine nicht-class-Abhängigkeit wie eine Datenbank-Verbindung oder application-Einstellung? Dann Band Klasse B zu den System.Configuration namespace, die Steigerung Ihrer Komplexität und Kopplung, während die Senkung Ihrer Kohärenz, die alle zu Kodieren details, die man einfach hätte externalisiert durch weglassen der default-Konstruktor.

Diese Art der Injektion vermittelt dem Leser, dass Sie haben erkannt, die Vorteile der entkoppelten design, aber nicht bereit sind, zu Begehen, um es. Wir alle wissen, dass, wenn jemand sieht, dass saftige, leicht, reibungsarm, Standard-Konstruktor, Sie gehen, zu nennen es egal, wie starr das Programm von diesem Punkt an. Sie können nicht verstehen, die Struktur Ihres Programms Lesen, ohne den source-code für die Standard-Konstruktor, der nicht eine option, wenn man nur verteilen Sie die Baugruppen. Dokumentieren Sie die Konventionen der Verbindung Zeichenfolge-name und die app-Einstellungen-Taste, sondern an dieser Stelle der code nicht auf eigenen Beinen stehen, und Sie legte die Beweislast auf die Entwickler, auf die Jagd nach dem richtigen Zauberspruch.

Optimieren von code, damit diejenigen, die es schreiben kann, ohne zu verstehen, was Sie sagen, ist eine Sirene-Lied, ein anti-pattern, dass führt letztendlich zu mehr Zeit verloren in der Entschlüsselung der Magie als die Zeit gespeichert, in der anfänglichen Aufwand. Entweder entkoppeln oder nicht; halten Sie einen Fuß in jedem Muster verringert sich der Fokus der beiden.
- Sorry, du hast nicht mich überzeugt. Zwei Konstruktoren--man macht die einfachen Sachen einfach, die andere macht die schwierigen Dinge möglich. Was wollen Sie mir zu tun scheint, um die einfachen Dinge schwierig.
- Szalapski: Mein Punkt ist 1) der Verbraucher kann code nicht verstehen, die Struktur Ihrer Programm ohne Quellcode oder Dokumentation, 2) nicht jede Abhängigkeit Konstruktor ist einfach, und 3) Ihrer Objekte nehmen an mehr wissen und Verantwortung, sodass deren Fokus. Wenn diese Punkte nicht überzeugen Sie sich, nichts jemals wird. Erstellung einer kompletten system, Stil und bewerten Sie selbst, ob es macht die Dinge einfacher.
InformationsquelleAutor Bryan Watts
1

Für was es Wert ist, all die standard-code, den ich gesehen habe, in Java funktioniert es so:
```
public class ThingMaker  {
    private IThingSource  iThingSource;

    public ThingMaker()  {
        iThingSource = createIThingSource();
    }
    public virtual IThingSource createIThingSource()  {
        return new DefaultThingSource();
    }
}
```
Jemand, der nicht will, eine DefaultThingSource Objekt außer Kraft setzen können createIThingSource. (Wenn möglich, den Anruf zu createIThingSource wäre irgendwo anderen als den Konstruktor.) C# nicht empfehlen überschreiben wie Java funktioniert, und es vielleicht nicht so offensichtlich, wie es sein würde, in Java, dass die Anwender können und müssen vielleicht Ihre eigenen IThingSource Umsetzung. (Noch so offensichtlich wie zu geben.) Meine Vermutung ist, dass die #3 ist der Weg zu gehen, aber ich dachte, ich würde erwähnen.
- +0:-.5: Sollte nicht nennen virtuals in einem ctor (100% sicher für die OO im Allgemeinen zu 99% sicher für Java). -.5: Doesnt Adresse der Kupplung Anliegen, +1: Eine interessante variation der Technik, die dem Menschen helfen kann denken, auch wenn Sie nicht verwenden Sie es als eine tatsächliche Lösung
- Bartelink: ja, virtual Anrufe in Konstruktoren sollten vermieden werden: stackoverflow.com/questions/119506/...
- Ich legte den virtuellen Aufruf im Konstruktor, um das Beispiel so einfach wie möglich. Aber in diesem Fall war es mir, dass es dort. Die "standard-code, den ich gesehen habe in Java" nicht den Aufruf der createIThingSource() entspricht im Konstruktor!
InformationsquelleAutor RalphChapin
0

Nur eine Idee - vielleicht ein bisschen mehr elegant, aber leider nicht loszuwerden, die Abhängigkeit:
- entfernen Sie den "bastard-Konstruktor"
- in der standard-Konstruktor, machen Sie die Quelle param default null
- dann überprüfen Sie für Quelle null ist, und wenn dies der Fall ist, ordnen Sie es "neue DefaultThingSource()" andernfalls was auch immer der Verbraucher injiziert
- Das blendet die Standard-Abhängigkeit von zukünftigen Entwicklern noch mehr, was nicht wünschenswert ist.
InformationsquelleAutor Yahia
0

Haben eine interne Fabrik (interne Bibliothek), die Karten die DefaultThingSource zu IThingSource, die aufgerufen wird, aus der Standard-Konstruktor.

Dies ermöglicht das "neue" der ThingMaker Klasse ohne Parameter oder irgendwelche Kenntnisse der IThingSource und ohne direkte Abhängigkeit von DefaultThingSource.
- Das klingt wie option #3, aber nur aufgeteilt in mehrere Klassen. Es nicht loszuwerden, die statische Abhängigkeit.
- ThingMaker ist nicht mehr staticly abhängig DefaultThingSource, wie es verwendet die Fabrik. Wenn Sie nun eine neue Implementierung der IThingSource, Sie einfach ändern Sie die Zuordnung in nur einem Ort, Ihre Fabrik.
- Ja, aber ThingMaker hat eine statische Abhängigkeit von der Fabrik, und die Fabrik hat eine statische Abhängigkeit von unseren Standard-Sache Quelle. Wir wollen, um loszuwerden, die statische Abhängigkeit insgesamt.
- Ah, das ist also eine theoretische übung dann? Weil ich nicht sehen können, der von praktischem Vorteil, dass keine statischen Abhängigkeiten auf allen in Ihrem Fall.
InformationsquelleAutor Jonathan van de Veen
0

Für wirklich öffentliche APIs, ich in der Regel behandeln diese mit einem zweiteiligen Ansatz:
1. Erstellen Sie einen Helfer innerhalb der API zu ermöglichen, eine API-Verbraucher-register "Standard" interface-Implementierungen der API mit Ihren IoC-container der Wahl.
2. Wenn es wünschenswert ist, zu ermöglichen, um die API-Verbraucher, die API zu nutzen, ohne Ihre eigenen IoC container, host ein optionales container innerhalb der API, der gefüllt ist die gleiche "default" - Implementierungen.
Der wirklich schwierige Teil hier ist zu entscheiden, Wann zu aktivieren, den container #2, und die best-choice-Ansatzes hängt stark von Ihrem geplanten API-Konsumenten.
- Gosh, klingt ziemlich kompliziert.
- Es tut nur weh das erste mal. 😉 Leider, wenn man ernsthaft versuchen zu unterstützen, um die Bedürfnisse des IoC und nicht-IoC-Benutzer als API-Konsumenten, die ich nicht sehen kann ein viel besserer Ansatz...
- Ich habe das Gefühl, dies würde jeder down the line versuchen, erhalten diesen code.
InformationsquelleAutor Nicole Calinoiu
0

Unterstütze ich option #1, mit einer Erweiterung: machen DefaultThingSource eine öffentliche Klasse. Deine Formulierung oben impliziert, dass DefaultThingSource werden vor der öffentlichkeit verborgen Konsumenten der API, aber ich verstehe deine situation, es gibt keinen Grund, nicht setzen Sie den Standard. Darüber hinaus können Sie leicht dokumentieren die Tatsache, dass außerhalb von besonderen Umständen ein new DefaultThingSource() können immer übergeben werden, um die ThingMaker.
- Ich war vorstellen, dass DefaultThingSource ist ja öffentlich und nicht intern.
- Ja, das wird funktionieren, aber gibt es irgendeinen Grund, warum dies ist ein besser Lösung?
InformationsquelleAutor JSBձոգչ

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.