Cześć, kiedy należy w Javce rozbijac serwis(i nie tylko) na interfejs? Kiedy ogólnie należy używać interfejsów czy też klas abstrakcyjnych?
Załóżmy, że mamy jakiś serwis do obsługi controllera, to czy należałoby najpierw stworzyć interfejs z potrzebnymi nam metodami a potem zaimplementować go w naszym serwisie razem z logiką czy to ogólnie rzecz ujmując jest to sprawa nie warta zachodu i przy pisaniu controllerów nie potrzeba tego oddzielać?
Interfejs jest swojego rodzaju narzuceniem standardu dla klas, które go implementują. Dzięki temu, podmieniając dwie klasy implementujące ten sam interfejs, możesz używać ich w taki sam sposób w kodzie. Interfejsem może być np. klasa Document, natomiast klasami implementującymi go PDFDocument i WordDocument.
Jak ktoś używa sensownego IDE to wydzielanie interfejsu jest zautomatyzowane, np: https://www.jetbrains.com/help/idea/extract-interface.html
kiowa72 napisał(a):
Cześć, kiedy należy w Javce rozbijac serwis(i nie tylko) na interfejs?
Dziwi mnie słowo "rozbijać", jakby chodziło o podział na mniejsze. Słowa są ważne.
Ewentualne wyprowadzenie interfejsu, u początku projektu czy podczas refaktoryzacji (uwaga Wibowit) tworzy interfejs o tej samej ilość metod publicznych, co klasa (główna klasa wejściowa serwisu).
W tym sensie nie jest "mniejsze". Nie wyobrażam sobie inaczej dla serwisów.
Można "rozbijać", np
Java 
class Duck implements ISwimmable, IQuackable {
}
I może to mieć sens, ale to inna rozmowa
Wybrane konstrukcje umożliwiają oderwanie się od wielu szczegółów, pozwalają pisać uogólniny kod po to, żeby dało się pewne rzeczy stosować wymiennie. Takim bardzo obrazującym przykładem są pluginy w przeglądarce, które możesz instalować bez potrzeby zmiany kodu w przeglądarce. Rozszerzasz wtedy projekt bez modyfikowania kodu, bez potrzeby aktualizowania testów itp - takie uogólnienia nie tylko są poręczne, ale również upraszczają pracę tym co tworzą te pluginy.
Niestety wypracowanie dobrej abstrakcji wymaga dogłębnej wiedzy w pewnym obszarze inaczej abstrakcje, które tworzysz będą dziurawe - a one działają zupełnie odwrotnie od wyżej wymienionego przykładu.
Możesz mieć np. serwis, który wystawia 5 metod, pod które robisz jeden interfejs. Docelowo chcesz napisać serwis do obsługi bramek płatności.
Projektując go myślisz o 1-2 dostawcach np dotpay, payu. Natomiast po miesiącu pada rozkaz przepięcia się pod innego dostawce, bo ma mniejszą prowizję i okazuje się, że on ma zupełnie inny flow. Cała praca, która poszła na wypracowanie abstrakcji idzie się rypać, a wraz z nią kod, który od niej zależy. Często zamiast wycofać się z decyzycji to wybrany problem pogłębia się jeszcze bardziej dodając do interfejsu kolejne metody, no i powstaje potworek z którego ciężko się wydostać.
Jak można tego uniknąć?
Musisz mieć wiedzę z wybranej dziedziny, jak jesteś początkujący to zamiast uogólniać to lepiej rób różne hacki, by lepiej zgłębić przestrzeń potencjalnych rozwiązań.
Unikaj pisania dużych abstrakcji. Jak już to próbuj wyznaczać małe interfejsy (np. po jednej metodzie), by uzyskać jedną oś obrotu. Tu pomyśl przez chwilę o zabawkach - najczęściej psują się te zabawki, które mają dużo ruchomych elementów lub te które mają za dużo wystających elementów. Nie inaczej jest w przypadku abstrakcji. Jak będziesz miał więcej metod lub jeśli będą one przyjmować bardzo specyficzne dane wówczas ich abstrakcja w miarę szybko może stać się dziurawa.
2.5) To rozszerenie punktu 2. Unikaj pisania kodu, które mają mieszankę w stylu: trochę wyglądu / trochę logiki / trochę baz itp - ponieważ takie partie kodu nawet niewielkie najszybciej mi pękały.
Dobrym przykładem (choć nie najlepszym jest iteracji po kolekcjach), dzięki pętlom mogą łatwiej przeskanować wartości. Są tu pewne kompromisy, bo bez wiedzy o typie ciężej jest ocenić złożoność algorytmu, a i też nie zawsze wiadomo w jakim porządku odczytasz elementy. Nie mniej taki wzorzec to krok w kierunku sekwencyjnego przetwarzania, pracy na leniwych czy też niekończących się sekwencjach - to drobna abstrakcja która ma wiele zastosowań.
Na koniec na pocieszenie dodam, byś pamiętaj że w firmach przeważnie będziesz utrzymywał produkt. I raczej nikt nie będzie się spodziewał, że napiszesz ogólną bibliotekę do rozwiązywania problemów z wybranej dziedziny. Najczęściej chodzi o tylko o jakiś wycinek, wykonany tak, aby za bardzo nie powtarzać 5 razy tego samego kodu. Także lepiej zejść na ziemie i więcej uwagi poświęcić modelowi danych od których jesteś 100 razy bardziej zależny. Polecam tą prezentacje, bo wydaje mi się, że łopatologicznie przedstawia pewne pułapki jakie sami sobie tworzymy: https://www.slideshare.net/Reg1773/puapki-programowania-obiektowego
iksdea jeśli chcę mieć trzy?wtedy klasa abstrakcyjna. To jest właśnie ta różnica o którą tak często pytają na rekrutacjach :)