W przypadkach, w których wymagane jest wstrzyknięcie zależności od konstruktora, jakie są względy związane z zastosowaniem iniekcji przez odniesienie vs. użycie boost :: shared_ptr?Injection dependency C++ - przez odniesienie lub przez boost :: shared_ptr?
Czy istnieje inny typowy sposób robienia tego? Jak to porównać do dwóch powyższych metod?
To Twój wybór, w jaki sposób chcesz zarządzać życiem obiektu, który wstrzykujesz. Ogólna architektura będzie prawdopodobnie decydować, który wybór ma największy sens. W przypadku odniesienia, coś na wyższym poziomie musi zarządzać czasem życia obiektu; z shared_ptr żywotność będzie zarządzana automatycznie.
Wcześniej użyłem obu metod.
Korzyści wynikające z zastosowania metody współdzielonego wskaźnika oznaczają, że można przekazać własność wstrzykniętych zależności konsumentowi.
Jeśli używasz podejścia opartego na referencjach, zniszczenie wstrzykniętych zależności jest dużo bardziej deterministyczne. To znaczy. pojawia się po zakończeniu przetwarzania przez wszystkich użytkowników.
Pamiętam, że widziałem kod, który zrobił to z unique_ptr (lub może auto_ptr). Wydaje się, że jest to lepsze niż "odniesienie": nie ma potrzeby zarządzania własnością wstrzykiwanego obiektu. To może być szybsze niż użycie shared_ptr: nie ma potrzeby liczenia odwołań. To może być bardziej mylące: wiąże się z przeniesieniem prawa własności, a auto_ptr ma pewne pułapki.
'unique_ptr' i' auto_ptr' nie daje możliwość udostępniania obiektu. Znowu, czy to będzie problem, zależy od ogólnej architektury. –
Jest to dobry wybór, jeśli obiekt jest właścicielem (nie udostępnia) wstrzykniętego obiektu. –
Pytanie, które należy sobie postawić, brzmi: kto jest właścicielem obiektu? W typowym scenariuszu DI jest to obiekt konsumencki. W takim przypadku przekazałbym surowy wskaźnik do konstruktora i zapisałbym go w coś podobnego do unique_ptr. Jeśli własność jest udostępniona lub nie jest jasna, użyj oczywiście shared_ptr.
Huh? Powinien * nigdy * być konsumentem w DI - a co, jeśli inne obiekty również muszą używać tej instancji? –
@ BlueRaja: Ściśle mówiąc, może być tak czy inaczej - DI jest ortogonalny względem dylematu agregacji a kompozycji. –
Nigdy nie podałbym wskaźnika RAW niczego. Jeśli nic innego zawijania wskaźnika w inteligentny wskaźnik dostarcza dokumentacji (w źródle), co ma się stać z obiektu przechodzącego RAW p; wskaźniki są po prostu straszne i mylące. –
+1: Kocham wstrzykiwanie zależności! – Nick
Używanie wskaźnika może pomóc w niektórych scenariuszach. Zobacz poniższą odpowiedź dla takiego przypadku podczas testowania klasy: http://stackoverflow.com/questions/5726580/mocking-c-classes-with-dependency-injection/5836747#5836747 – Jonathan