Hej,
Zastanawiam się która praktyka (i dlaczego) jest lepsza:
Dziękuje Panowie :)
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.
Rozumiem, że to jest tylko kwestia pozostawienia kodu łatwiejszego do rozbudowania?
Nie ma to żadnych uzasadnień wydajnościowych, optymalizacyjnych?
Dziękuje za wyjaśnienie :)
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 ).
Zarejestruj się i dołącz do największej społeczności programistów w Polsce.
Otrzymaj wsparcie, dziel się wiedzą i rozwijaj swoje umiejętności z najlepszymi.
Shalomprzecież ten format się nie zmieni;) Widziałem też np. migracje zewnętrznego serwisu z SOAP na REST i wygodnie kiedy masz to opakowane w jakis ładny interfejs i piszesz sobie tylko nową implementacje.