dependency injection class or interface

0

Hej,

Zastanawiam się która praktyka (i dlaczego) jest lepsza:

  1. Wewnątrz przykładowego obiektu zadeklarować pole klasy Sample z adnotacją @Inject
  2. Wewnątrz przykładowego obiektu zadeklarować pole interfejsu SampleImpl z adnotacją @Inject
    Zakładam, ze SampleImpl implementuje Sample i ma dokładnie te same metody publiczne.
    Szukałam na SO, ale szukam prostej, klarownej interpretacji.

Dziękuje Panowie :)

4

A jak będziesz kiedyś chciała podmienić SampleImpl na SampleImpl2? W ogóle generalnie stosuje się interfejsy a nie konkretne klasy, niezależnie od tego czy masz tam DI czy też nie. Dzięki temu masz kod powiązany jedynie kontraktami związanymi z dostarczanymi metodami, a nie powiązany z konkretnymi implementacjami. Taki kod potem dużo prościej zmieniać i rozwijać.

Wczoraj na przykład dane byly zapisywane w pliku, dziś w bazie danych a jutro klient sobie zażyczy opcji że w chmurze. A dla ciebie w całym kodzie to kwestia zaimplementowania kolejny raz interfejsu DataRepository, reszta kodu pozostaje bez zmian, bo polega tylko na tym interfejsie.

Oczywiście nie ma też co się dać zwariować. Jeśli wiesz na pewno że jakaś klasa na pewno nie będzie nigdy zmieniona to nie warto wydzielać interfejsu "na zapas". Niemniej użycie DI sugeruje że jednak ta zależność moze ulegać zmianie / być podmieniana za pomocą konfiguracji.

0

Rozumiem, że to jest tylko kwestia pozostawienia kodu łatwiejszego do rozbudowania?
Nie ma to żadnych uzasadnień wydajnościowych, optymalizacyjnych?
Dziękuje za wyjaśnienie :)

1
Shalom napisał(a):

A jak będziesz kiedyś chciała podmienić SampleImpl na SampleImpl2? W ogóle generalnie stosuje się interfejsy a nie konkretne klasy, niezależnie od tego czy masz tam DI czy też nie. Dzięki temu masz kod powiązany jedynie kontraktami związanymi z dostarczanymi metodami, a nie powiązany z konkretnymi implementacjami. Taki kod potem dużo prościej zmieniać i rozwijać.

Oczywiście nie ma też co się dać zwariować. Jeśli wiesz na pewno że jakaś klasa na pewno nie będzie nigdy zmieniona to nie warto wydzielać interfejsu "na zapas". Niemniej użycie DI sugeruje że jednak ta zależność moze ulegać zmianie / być podmieniana za pomocą konfiguracji.

Ogólnie się z tym nie zgadzam! (Pomijając nawet moje krytyczne zdanie na temat Springa... )

YAGNI

Jak masz jedną implementację to używasz bezpośrednio i koniec. Nie ma sensu bawić się w interfejsy (zwykle).

Jak się pojawia druga implementacja to wtedy dopiero warto wprowadzić interfejs (przecież to w XXI wieku proste).

Trudno też powiedzieć, że jakaś klasa nigdy nie będzie potrzebowała drugiej implementacji itp. software na ogół żyje, reguły się zmieniają. Klienci piją. Ale moment na wprowadzenie interfejsu jest właśnie i dopiero wtedy, kiedy się taka druga, trzecia implementacja pojawia. (Albo już wiesz na 100%, że się zaraz pojawi ).

1 użytkowników online, w tym zalogowanych: 0, gości: 1