Рамки введення залежностей, такі як Google Guice, дають таку мотивацію їх використання ( джерело ):
Щоб побудувати об’єкт, спочатку будуєте його залежності. Але для побудови кожної залежності потрібні її залежності тощо. Тож коли ви будуєте об’єкт, вам справді потрібно будувати графік об’єкта.
Створення графіків об'єктів вручну є трудомістким (...) і ускладнює тестування.
Але я не купую цей аргумент: Навіть не маючи структури введення залежності, я можу писати класи, які прості в інстанції та зручні для тестування. Наприклад, приклад зі сторінки мотивації Guice можна переписати наступним чином:
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)
{
...
}
}Тож можуть існувати й інші аргументи для фреймворків введення залежностей ( які не виходять з цього питання !), Але просте створення графічних об'єктних графіків - це не один з них, чи не так?
new ShippingService().