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? Pytam bo zgłupiałem trochę #programowanie #naukaprogramowania
ś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? Pytam bo
@aligator88: @wytrzzeszcz: Zależy, w javie EE panuje wielki kult abstrakcji, najlepiej by twój projekt od zarządzania stroną banku po zmienianiu kilku klas implementacji potrafił obsługiwać toster. W innych miejscach zazwyczaj jest spokojniej, ale tak to chyba sobie warto przemyśleć, co w twoim programie powinno być abstrakcyjnie zrobione, od razu można wydzielić sobie jakieś części związane z API itd. Ale jak piszesz już ten właściwy kod to nie ma
@aligator88: kluczem jest słowo niepotrzebnych. Chodzi o to, żeby nie dodawać abstrakcji na wyrost, tam gdzie ich nie potrzeba.
Jak piszesz aplikację do zarządzania flotą samochodów osobowych dla przedstawicieli handlowych, to nie są ci potrzebne abstrakcje sięgające wszystkich pojazdów w tym motocykli, czy jeszcze wyższe abstrakcje wszystkich środków lokomocji w tym samolotów. To by były właśnie niepotrzebne warstwy abstrakcji.
W myśl tych zasad wprowadziłbyś abstrakcję pojazdów ruchu lądowego dopiero jakby
@aligator88: overengineering to najgorsze co może spotkać kod Wymyślasz z powietrza "jakie zmiany mogą być potrzebne" i zazwyczaj wymyślasz źle. Potem masz do wyboru robić hacka niezgodnego z architekturą albo mozolnie wszystko przebudowywać. Lepiej od początku budować pod obecny problem, a zmiany wprowadzać dopiero jak są potrzebne.
@aligator88: to nie jest tak, że jest jedna żelazna reguła której trzeba się trzymać. Jeżeli wprowadzisz więcej abstrakcji na początku to później Twój system będzie bardziej elastyczny na zmiany, ale więcej się nakodzisz na początku, jak będzie mniej abstrakcji to zmiany będą bardziej kosztowne ale prototyp napiszesz szybciej. To tylko Twój wybór i odpowiedzialność jak sobie zaprojektujesz.
@aligator88: Nie musi - abstrakcja to jedna z cech, które czasami się przydają, czasami niekoniecznie. A ogólnie jak to w życiu, najgorzej, gdy ktoś przesadza w którąś stronę :)
@nunczako: Kompletnie pomijasz, że im więcej abstrakcji tym większy koszt utrzymania kodu, więcej miejsc gdzie mogą być bugi a nawet potencjalnie zaciemnianie kodu i zmniejszona czytelność. Niepotrzebne warstwy abstrakcji mają zdecydowanie więcej minusów niż potencjalnych plusów, także gdy są wątpliwości, należy z abstrakcji zrezygnować.
@aligator88: Zwinne programowanie i Uncle Bob tworzac agile manifesto bazowal na swoich doswiadczeniach jako konsultanta wdrzajacego projekty u klientow. Podejscie to nie bedzie pasowalo do kazdego rodzaju projektu, firmy, kleinta.
Podejscie oraz to jak wytwarzasz oprogramowanie musisz dopasowac do kontextu, wymagan, rynku, produktu, klienta. Dlatego jako doswiadczony dev masz placone wiecej bo rozumiesz
@meohaw: no tak, zgadzam się. Najlepsze to jest jak w aplikacji "byznesowej" wywołujemy metodę UserController#findUser która wywołuje metodę interfejsu IUserService#findUser, do tego interfejsu wstrzykujemy właściwy serwis oczywiście implementujący metodę "findUser" z której wywołujemy metodę UserDao#findUser która wywołuje metodę EntityManager#find(id, User.class) :)
@aligator88: z praktyki - abstrakcje warto tworzyc jak jestes pewny ze sa lub za chwile beda potrzebne, robienie ich na wyrost konczy sie tym ze masz abstrakcje tam gdzie ich nie potrzebujesz a tam gdzie akurat, zgodnie z nowymi potrzebami czy zleceniem klienta, ich potrzebujesz to albo ich nie ma (bo nie przewidziales ze akurat w tym miejscu sie przydadza) albo sa nieprzydatne (bo akurat problem ktory masz rozwiazac nie
#programowanie #naukaprogramowania
@aligator88: chyba ok chodzi o brzytwe okacham
W innych miejscach zazwyczaj jest spokojniej, ale tak to chyba sobie warto przemyśleć, co w twoim programie powinno być abstrakcyjnie zrobione, od razu można wydzielić sobie jakieś części związane z API itd.
Ale jak piszesz już ten właściwy kod to nie ma
@aligator88: martin tak twierdzi w jednej ze swych książek :)
Jak piszesz aplikację do zarządzania flotą samochodów osobowych dla przedstawicieli handlowych, to nie są ci potrzebne abstrakcje sięgające wszystkich pojazdów w tym motocykli, czy jeszcze wyższe abstrakcje wszystkich środków lokomocji w tym samolotów. To by były właśnie niepotrzebne warstwy abstrakcji.
W myśl tych zasad wprowadziłbyś abstrakcję pojazdów ruchu lądowego dopiero jakby
Wymyślasz z powietrza "jakie zmiany mogą być potrzebne" i zazwyczaj wymyślasz źle. Potem masz do wyboru robić hacka niezgodnego z architekturą albo mozolnie wszystko przebudowywać.
Lepiej od początku budować pod obecny problem, a zmiany wprowadzać dopiero jak są potrzebne.
Natomiast w wiekszosci projektow abstrakcje i inne cuda na kiju sa niepotrzebne.
Tutaj tez odesle do innego klasyka - http://www.joelonsoftware.com/articles/fog0000000018.html
Podejscie oraz to jak wytwarzasz oprogramowanie musisz dopasowac do kontextu, wymagan, rynku, produktu, klienta. Dlatego jako doswiadczony dev masz placone wiecej bo rozumiesz