Abhängigkeitsinjektion in C ++

stimmen
23

Dies ist auch eine Frage , die ich in einem Kommentar gefragt in einem von Miško Hevery der Google - Gespräche , die mit Dependency Injection zu tun hatten , aber es wurde in den Kommentaren begraben.

Ich frage mich, wie kann die Fabrik / builder Schritt die Abhängigkeiten zusammen verdrahten kann in C ++ arbeiten.

Das heißt, wir haben eine Klasse A, die auf der Builder B. hängt B wird in der Halde zugewiesen, einen Zeiger auf B in A Konstruktor übergeben und gleichzeitig in den Heap und liefern einen Zeiger auf A. Zuordnen

Wer reinigt anschließend nach oben? Ist es gut, der Erbauer aufzuräumen zu lassen, nachdem es fertig ist? Es scheint, die richtige Methode zu sein, da in dem Vortrag heißt es, dass der Bauherr sollte Setup-Objekte, die die gleiche Lebensdauer oder zumindest die Abhängigkeiten haben eine längere Lebensdauer (Ich habe auch eine Frage auf, dass) zu erwarten ist. Was ich in Code bedeuten:

class builder {
public:
    builder() :
        m_ClassA(NULL),m_ClassB(NULL) {
    }
    ~builder() {
        if (m_ClassB) {
            delete m_ClassB;
        }
        if (m_ClassA) {
            delete m_ClassA;
        }
    }
    ClassA *build() {
        m_ClassB = new class B;
        m_ClassA = new class A(m_ClassB);
        return m_ClassA;
    }
};

Nun, wenn es eine Abhängigkeit ist, dass es uns länger als die Lebensdauer des Objekts dauert in erwartet wird injizieren (etwa ClassC ist, dass die Abhängigkeit) Ich verstehe, dass wir die Build-Methode, um so etwas wie ändern sollten:

ClassA *builder::build(ClassC *classC) {
    m_ClassB = new class B;
    m_ClassA = new class A(m_ClassB, classC);
    return m_ClassA;
}

Was ist Ihr bevorzugter Ansatz?

Veröffentlicht am 09/12/2008 um 15:26
quelle vom benutzer
In anderen Sprachen...                            


8 antworten

stimmen
13

Dieser Vortrag ist über Java und Dependency Injection.

In C ++ wir versuchen , nicht um RAW - Zeiger zu übergeben. Dies liegt daran , ein RAW Zeiger kein Eigentum Semantik zugeordnet sein. Wenn Sie kein Eigentum haben , dann wissen wir nicht , die zur Reinigung des Objektes verantwortlich ist.

Ich finde , dass die meiste Zeit Dependency Injection wird über Referenzen in C ++ durchgeführt.
In den seltenen Fällen , in denen Sie Hinweise, wickeln Sie sie in verwenden müssen std :: unique_ptr <> oder std :: shared_ptr <> je nachdem , wie Sie verwalten möchten Eigentum.
In Fall können Sie nicht C ++ 11 - Funktionen verwenden, verwenden Sie std :: auto_ptr <> oder boost :: shared_ptr <>.

Ich möchte auch darauf hinweisen, dass C ++ und Java Arten der Programmierung sind jetzt so weit auseinander, dass die Art von einer Sprache in die andere Anwendung wird unweigerlich zu einer Katastrophe führen.

Beantwortet am 09/12/2008 um 15:47
quelle vom benutzer

stimmen
9

Das ist interessant, DI in C ++ mit Hilfe von Vorlagen:

http://adam.younglogic.com/?p=146

Ich denke, der Autor macht die richtigen Schritte nicht Java DI in C ++ übersetzen zu wörtlich. die lesenswert.

Beantwortet am 23/12/2009 um 02:08
quelle vom benutzer

stimmen
6

Ich habe vor kurzem von dem DI - Virus infiziert worden. Ich denke , dass es eine Menge von Komplexität Problemen löst, vor allem des automatisierten Teil. Ich habe einen Prototyp geschrieben , die Sie in einer hübschen C ++ Art und Weise verwenden DI können, oder zumindest ich denke schon. Sie können einen Blick auf den Code Beispiel nehmen hier: http://codepad.org/GpOujZ79

Die Dinge, die offensichtlich fehlen: kein Scoping, keine Bindung der Schnittstelle zur Implementierung. Letzteres ist recht einfach zu lösen, die ehemalige, Ich habe keine Ahnung.

Ich wäre dankbar, wenn jemand hier eine Stellungnahme zu dem Code.

Beantwortet am 10/05/2010 um 17:39
quelle vom benutzer

stimmen
3

Verwenden Sie RAII.

einen rohen Zeiger auf jemand Gabe ist die gleiche, sie Eigentum wie Gabe. Wenn das nicht das, was Sie tun mögen, sollten Sie ihnen eine Art Fassade geben, der auch weiß, wie das betreffende Objekt zu bereinigen.

shared_ptr <> kann dies tun; das zweite Argument des Konstruktor kann eine Funktion Objekt sein, das weiß, wie das Objekt zu löschen.

Beantwortet am 09/12/2008 um 17:40
quelle vom benutzer

stimmen
2

Basierend auf meiner eigenen Erfahrung ist es am besten klare Eigentümer Regeln haben. Für kleine konkrete Objekte, ist es am besten, direkte Kopie zu verwenden Quer Abhängigkeit zu vermeiden.

Manchmal Quer Abhängigkeit ist unvermeidlich, und es gibt kein klares Eigentum. Zum Beispiel (m) A Instanzen eigene (n) B-Instanzen und bestimmte B-Instanzen können von mehreren Als gehören. In diesem Fall ist der beste Ansatz Referenzzählung auf B, in der Art und Weise ähnlich wie COM Referenzzählung anzuwenden. Alle Funktionen, die den Besitz von B * nehmen müssen Referenzzähler erhöhen zuerst, und es verringern, wenn der Besitz freizugeben.

Ich vermeide auch mit boost :: shared_ptr, da es eine neue Art (shared_ptr und B * werden zwei unterschiedliche Typen) erzeugt. Ich fand, dass es mehr Kopfschmerzen bringt, wenn ich Methoden hinzufügen.

Beantwortet am 23/12/2009 um 17:04
quelle vom benutzer

stimmen
2

In C ++, in der Regel, wenn man die Dinge richtig gemacht, müssen Sie nicht in den meisten Fällen Destruktoren überhaupt zu schreiben. Sie sollten intelligente Zeiger verwenden, um Dinge automatisch zu löschen. Ich denke, Baumeister Sie sieht nicht wie der Besitzer der Klasse A und Klasse B-Instanzen. Wenn Sie nicht verwenden Smart Pointer mögen, sollten Sie darüber nachdenken, Objekte Lebensdauer und ihre Besitzer.

Beantwortet am 09/12/2008 um 16:14
quelle vom benutzer

stimmen
2

Die Dinge werden kompliziert, wenn Sie auf die Eigentumsfrage nicht begleichen ein für allemal. Sie müssen einfach in der Implementierung entscheiden, ob es möglich ist, dass Abhängigkeiten leben länger als die Objekte, die sie in injiziert werden.

Persönlich würde ich nicht sagen: das Objekt, in dem die Abhängigkeit injiziert wird, wird danach aufzuräumen. Der Versuch, sie durch den Builder zu tun, bedeutet, dass der Builder als länger leben muß sowohl die Abhängigkeit und das Objekt, in dem es eingespritzt wird. Dies verursacht mehr Probleme als sie löst, meiner Meinung nach, weil der Erbauer nicht dient nicht mehr nützlichen Zweck nach dem Bau mit der Dependency Injection abgeschlossen war.

Beantwortet am 09/12/2008 um 15:33
quelle vom benutzer

stimmen
1

Sie können auch die überprüfen FFEAD Dependency Injection . Es bietet DI auf den Linien von Spring für JAVA und hat eine unaufdringliche Art und Weise mit den Dingen umzugehen. Es hat auch viele andere wichtige Funktionen wie in integrierten AJAX - Unterstützung, Spiegelung, Serialisierung, C ++ Interpreter, Geschäft Komponenten für C ++, ORM, Messaging, Web-Service, Themen-Pools und einen Application - Server , die alle diese Funktionen unterstützt.

Beantwortet am 10/08/2010 um 08:31
quelle vom benutzer

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more