Z tydzień temu natknąłem się na serię artykułów na blogu http://www.yegor256.com których autor wydaje się być fanatykiem OOP. Wiele z nich mnie mocno zaintrygowało, zdecydowana większość jest dla mnie dość kontrowersyjna, więc chciałbym poznać waszą opinię na temat dobrych praktyk. Tematów jest wiele, więc w tym wątku chciałbym poruszyć te wymienione w temacie, które imo są całkiem ze sobą powiązane.
-
Getery i setery = zło -> http://www.yegor256.com/2014/09/16/getters-and-setters-are-evil.html - czytając artykuł odnoszę wrażenie, że jako formę zastępczą autor zaleca to samo, tylko inaczej nazwane. Rozumiem, że nazewnictwo jest bardzo ważne, ale biorąc pod uwagę ile pobocznych projektów wspiera powszechnie przyjemne nazewnictwo set* / get* to trochę rzucanie sobie kłód pod nogi. Naprawdę między dog.giveBall() a dog.getBall() jest aż taka różnica, że mamy rezygnować np. ze wsparcia ORMów, bibliotek mapujących klasy na XMLe / JSONy czy innych rzeczy (np. projekt Lombok)? I dlaczego traktowanie niektórych obiektów w np. javie jako rozbudowane data holdery jest aż takie złe? Int jest ok, ale klasa reprezentująca współrzędne punktów kratowych, która zawiera 2 inty x i y z seterami i geterami już nie jest ok? Czemu?
-
Tu pojawia się 'rozwiązanie' = printery -> http://www.yegor256.com/2016/04/05/printers-instead-of-getters.html - z jednej strony wygląda to ciekawie, bo rzeczywiście dość logiczne, że to np obiekt Ball winien mieć metodę 'toXml' - Podchodzisz do piłki i mówisz "Pokaż mi swoją reprezentację w xml". Ale w czym gorsze są konwertery, które tym zarządzają? Co jest w złego we wzięciu piłki i podejściu do konwertera "Ej stary masz tu piłkę, daj mi jej reprezentację xmlową, bo TY się na tym ZNASZ."?
-
ORM to zło (http://www.yegor256.com/2014/12/01/orm-offensive-anti-pattern.html oraz http://www.yegor256.com/2016/07/06/data-transfer-object.html) - miałem okazję się łączyć przez JDBC do bazy. No da się. Ale jak użyłem javowego Hibernate'a albo już w ogóle Spring Data to była czysta przyjemność. 5 minut i wszystko gotowe, podstawowe SQLki porobione same z siebie, jak potrzebuję jakiejś wyszukanej to nie ma problemu żebym ją sam napisał. No jest to po prostu wygodne. Minusy z mojej strony? Odkąd dowiedziałem się i zrozumiałem, że dobrą praktyką jest robienie obiektów immutable, to jednak przeszkadzał mi fakt, że jak klasa Book reprezentuje encję książki w bazie danych, to jej pola nie mogły być finalne. No boli. Tutaj moje pytanie to bardziej doświadczonych - jak to obejść? Czy jest sens dokładać kolejną warstwę, która zawiera te same klasy i pola, tylko że immutable?
-
No właśnie, immutable... http://www.yegor256.com/2014/06/09/objects-should-be-immutable.html - zgadzam się, Immutable jest bardzo spoko. Ale zastanawia mnie kwestia wydajności. Co jeśli mamy rozbudowaną klasę i bardzo często wykonujemy jakąś zmianę w jej środku? Nie wiem, np. klasa FermaKrólików, które ma trochę pól w sobie, w tym jakiegoś integera odpowiadającego za ilość królików (jak wiadomo ta liczba może dość szybko rosnąć :)). I teraz za każdym razem gdy wywołam ferma.dodajKrólika(), która mi zwiększa ilość królików, to ta metoda powinna stworzyć nową instancję klasy FermaKrólików, która w konstruktorze dostanie to samo co obecna ferma, z jednym wyjątkiem - nową ilością królików. Czy to nie jest średnio optymalne? A co jeśli w tej klasie trzymamy Immutable Listę Królików? I niech ich będzie milion. Za każdym razem mamy przepisywać milion królików + 1 do nowej listy, którą potem zamieniamy na immutable, np. za pomocą buildera? No bo to mi też nie wydaje się optymalne.