Jedno słowo: Nie.
Więcej słów: wstrzyknięcie zależności jest dokładnie tym. Jest to środek, za pomocą którego wprowadzasz zasoby, od których zależy inny obiekt, ale nie powinny znać skomplikowanych szczegółów z innego źródła. Używanie DI nie oznacza, że NIC w twoim programie nie powinno wiedzieć, jak utworzyć dowolny inny obiekt; w rzeczywistości uważam, że dla nietrywialnego programu bardzo niemożliwe jest całkowite uniknięcie „nowego” słowa kluczowego (lub alternatyw opartych na odbiciu). Jednak DI oznacza, że obiekty, które nie powinny MIEĆ wiedzieć, jak tworzyć złożone obiekty wymagające wielu zależności, które ściśle połączą ten obiekt z drugim, nie powinny mieć całej tej ściśle powiązanej wiedzy.
Badałbym dwie główne teorie projektowania oprogramowania O / O, GRASP i SOLID. GRASP powie ci, abyś przestudiował cel obiektu i zapytał siebie: „Czy ten obiekt powinien być odpowiedzialny za tworzenie nowych obiektów tego innego rodzaju? Czy to część„ opisu zadania ”tego obiektu?” SOLID idzie o krok dalej: „S” oznacza „zasadę pojedynczej odpowiedzialności”, która jednoznacznie stwierdza, że obiekt powinien mieć jedno zadanie i powinien być jedynym obiektem w programie, który wykonuje to konkretne zadanie.
Dlatego GRASP ogólnie zachęca do przejrzenia istniejących klas, dla których tworzenie tych nowych obiektów, i znalezienia takiej, dla której zadanie tworzenia tego obiektu pasuje do tego, co obiekt już robi, przy zachowaniu pożądanego poziomu „spójności”. SOLID powie ci, że spójność jest kluczowa; zadanie tworzenia tych obiektów powinno zostać powierzone jakiejś fabryce, która powinna zostać wprowadzona do twojej klasy. Myślę, że wraz ze wzrostem złożoności twojego programu, przestrzeganie którejkolwiek z tych metod, z chęcią refaktoryzacji, będzie skutkować bardzo podobnymi architekturami.