Zawsze myślałem, że w OOP powinno się operować na abstrakcjach. Teraz czytam "Zwinne wytwarzanie oprogramowania" Martina i czytam, że: "Nie chcemy, aby projekt był przeładowany dużą ilością niepotrzebnych abstrakcji. Przeciwnie, często czekamy, aż abstrakcja staje się potrzebna, i dopiero wtedy ją wprowadzamy." oraz "Przeciwdziałanie przedwczesnym abstrakcjom jest tak samo ważne jak same abstrakcje". To jak to w koncu jest? Gdy wprowadzam jakaś zmianę lub ulepszenie to dopiero mam wprowadzać interfejsy i zmieniać cały kod?
0
2
Najogólniej rzecz ujmując interfejs wymusza w klasie, która po nim dziedziczy implementację swoich metod i zachowań. Jeżeli pracujemy w grupie i tworzymy klasę do obsługi bazy danych, a nagle zaistnieje potrzeba zmiany silnika bazy danych z MySQL na MSSQL to nie trzeba będzie zmieniać zależnych od tej klasy modułów, ponieważ posiada ona zachowania zdefiniowane za pomocą interfejsów. Implementując nowy silnik będzie trzeba trzymać się prototypów funkcji więc reszta programu nie powinna nawet zauważyć zmiany. Jest to bezcenne wręcz przy dużych projektach, ponieważ interfejsować można całe klasy usługowe i zmieniać je niezależnie od reszty aplikacji. Twórca interfejsu ma pewność, że klasa, która go wykorzystuje będzie posiadała implementacje wszystkich metod.
Taka jest idea, ale też jak wiadomo co za dużo to niezdrowo i jak nadźgasz wszędzie interfejsów to też jest niedobrze.
2
No ja np. nie tworzę interfejsów do każdej klasy, tylko dlatego, że ktoś uważa, że bez tego się nie da testować ani skonfigurować kontenera IoC. Interfejs, który ma tylko jedną rzeczywistą implementację, to moim zdaniem nie jest rozsądne rozwiązanie. A, że Martin poza tymi głupotami, które wygaduje o Agile, to w sumie dość ogarnięty koleś, to mógł dojść do takich samych wniosków jak ja.
0
Abstrakcja nie jest darmowym posiłkiem, idąc w abstrakcję zyskujemy zwykle elastyczność, a tracimy prostotę i trochę wydajności. Rzadko kiedy w programowaniu mamy sytuację że dostajemy coś za darmo, zwykle właśnie musimy ustalić jakiś kompromis pomiędzy wymaganiami niefunkcjonalnymi, w angielskiej literaturze to się ładnie nazywa "trade off". Całe piękno programowania polega na tym, że dla każdej aplikacji optymalny kompromis będzie inny.
I wbrew pozorom Martin właśnie bardzo forsuje abstrakcje(pomimo tych uwag które przytoczyłeś), w szczególności w swych starszych materiałach. W nowszych materiałach łagodzi już swój ton, w szczególności na swoim blogu jak np tutaj http://blog.8thlight.com/uncle-bob/2013/03/08/AnOpenAndClosedCase.html, gdzie zwykle na swoja obronę przytacza, że był młody i niedojrzały, a teraz jest mądrzejszy :D.
Więc podsumowując idąc w abstrakcję zyskujesz elastyczność, ale nie zawsze tą elastyczność potrzebujesz i odbywa się to jakimś kosztem, stąd te uwagi Martina (wielkiego zwolennika abstrakcji i jeszcze większego zwolennika TDD i Agilu) :D
4
@Wielki Terrorysta to jest trochę kwestia zasad YAGNI i KISS. Chodzi o to żeby nie komplikować kodu w imię mało prawdopodobnej potencjalnej elastyczności. Jeśli wiesz że będzie tylko jedna klasa prezentująca pewne zachowanie to nie ma sensu wydzielać z niej 3 interfejsów i 2 klas abstrakcyjnych "na wypadek jakby trzeba było zrobić kilka podobnych klas". Jak faktycznie pojawi się potrzeba napisania takich klas to wtedy sobie zrobisz ekstrakcje jakiejś abstrakcji.
0
Osobiście wziąłem sobie do serca akapit o API [0] i próbuję pisać interfejsy jakbym pisał API.
[0] https://docs.oracle.com/javase/tutorial/java/IandI/createinterface.html