Ramy wstrzykiwania zależności, takie jak Google Guice, dają następującą motywację do ich użycia ( źródło ):
Aby zbudować obiekt, najpierw zbuduj jego zależności. Ale aby zbudować każdą zależność, potrzebujesz jej i tak dalej. Więc kiedy budujesz obiekt, naprawdę musisz zbudować wykres obiektu.
Ręczne budowanie wykresów obiektów jest pracochłonne (...) i utrudnia testowanie.
Ale nie kupuję tego argumentu: nawet bez struktury wstrzykiwania zależności mogę pisać klasy, które są łatwe do utworzenia i wygodne do przetestowania. Na przykład przykład ze strony motywacyjnej Guice można przepisać w następujący sposób:
class BillingService
{
private final CreditCardProcessor processor;
private final TransactionLog transactionLog;
// constructor for tests, taking all collaborators as parameters
BillingService(CreditCardProcessor processor, TransactionLog transactionLog)
{
this.processor = processor;
this.transactionLog = transactionLog;
}
// constructor for production, calling the (productive) constructors of the collaborators
public BillingService()
{
this(new PaypalCreditCardProcessor(), new DatabaseTransactionLog());
}
public Receipt chargeOrder(PizzaOrder order, CreditCard creditCard)
{
...
}
}
Mogą więc istnieć inne argumenty za szkieletem wstrzykiwania zależności ( które nie mieszczą się w tym pytaniu !), Ale łatwe tworzenie grafów obiektowych do testowania nie jest jednym z nich, prawda?
new ShippingService()
.