[krunky]

Jest metoda w kontrolerze, która zwraca listę zamówień z wartością mniejszą od konkretnej kwoty. Ja dostałem taska żeby dorobić podobną metodę ale taką która zwraca zamówienia z wartością mniejszą pierwszej kwoty i wyższe od drugiej podanej kwoty. Ta pierwsza metoda używa kilku metod w serwisie i zamiast kopiować to wszystko chciałbym do tych metod dodać parametr varargs. Czyli było getOrders(int maxValue), będzie getOrders(int maxValue, int... minValue). Wtedy wystarczą minimalne zmiany. Czy takie rozwiązanie jest ok?
#programowanie #java #naukaprogramowania

[PaaD]

@krunky: na ostatnie pytanie odpowiem pytaniem: czego powinien spodziewać się ktoś, kto wywoła metodę tak: getOrders(100, 200, 300)? ( ͡° ͜ʖ ͡°)

[ly000]

@krunky: nie jest ok. sam pomysł, żeby robić to w oddzielnej metodzie zamiast zmodyfikować istniejącą też jest raczej słaby. maxValue również nie powinno być przekazywane na sztywno jak int, tylko jako obiekt klasy reprezentującej parametry filtrowania. to ułatwiłoby / ułatwi dalszą rozbudowę kodu.

[krunky]

@Paad @ly000 Dzięki!

[Krolik]

maxValue również nie powinno być przekazywane na sztywno jak int, tylko jako obiekt klasy reprezentującej parametry filtrowania. to ułatwiłoby / ułatwi dalszą rozbudowę kodu.

@ly000: YAGNI - jak będzie trzeba to się zrefaktoryzuje.

[Krolik]

sam pomysł, żeby robić to w oddzielnej metodzie zamiast zmodyfikować istniejącą też jest raczej słaby

@ly000: a niby dlaczego?

[ly000]

a niby dlaczego?

@Krolik: dlatego że filtrowanie ma to do siebie, że może składać się z wielu parametrów, które powinno się ze sobą dowolnie łączyć. nie ma sensu tworzyć osobnej metody / endpointu dla każdego parametru filtrowania / sortowania czy czego tam jeszcze, to byłoby niepraktyczne i niefunkcjonalne. można się nawet pokusić o zrobienie generycznego filtrowania dla dowolnej liczby parametrów i które byłoby konfigurowalne. SOLID się kłania, zwłaszcza literka O.

YAGNI

[Krolik]

@ly000: i tak i nie, podejście które próbujesz promować często powoduje niepotrzebny wzrost komplikacji całego rozwiązania. Bo zamiast prostego filtrowania po max / min zaraz będziesz mieć cały silnik wyszukiwania wielokryterialnego i task który można było zrobić w godzinę zajmie miesiąc, bo okaże się że wcale nie można dowolnie łączyć, bo baza danych np. takiego dowolnego łączenia nie obsłuży dostatecznie wydajnie itp. I open jeszcze ktoś to będzie musiał utrzymywać. API

[ly000]

@Krolik: ale ja nie mówię, że od razu ma robić "silnik wyszukiwania wielokryterialnego", tylko żeby zrezygnował z przekazywania surowych intów na rzecz bardziej reprezentatywnych obiektów, które mogą być łatwo rozszerzalne -Open-closed principle, oczywiście tam gdzie jest to możliwe.

[Krolik]

@ly000: ale w wymaganiach ma min i max które są intami. To co proponujesz to już jest klasyczny overengineering. Po grzyba mają być rozszerzalne jak w wymaganiach nic nie masz o tym że mają być rozszerzalne? W 99% przypadków ludzie źle przewidują co ma być rozszerzalne a im więcej miejsc rozszerzania systemu tym system bardziej skomplikowany i trudniejszy do zrozumienia. W ogóle open-closed principle to jeden z największych gniotów w SOLID

[ly000]

@Krolik: to nie jest overenginnering, chociażby dlatego, że to m. in. dobrze rozwiązuje problem op związany z powtarzalność kodu. a używanie typów dodających znaczenie ma sens od samego początku, nawet jeśli typ składa się z jednego pola.

[Hulleck123]

@krunky @ly000: @Krolik: opakowałbym w obiekt, bo jak kontroler to jest to najprawdopodobniej jakieś API i potem jeb*ac się z refaktorem na fe to podziękuje. Niby tak jak Krolik pisze 10 min roboty, ale jednak nie. W przypadku gdyby to był jakiś obiekt nie wystawiający API na zewnątrz to nie ma co kombinować. Dzisiaj dołożenie interfejsu, jakaś zmiana argumentów wywołania itp to jest banał.

[Krolik]

@ly000: oznaczenie typów dodających znaczenie ma sens, ale o to byłoby co innego: wtedy zamiast dwóch intów metoda powinna przyjmować dwie wartości typu OrderId - i to jak najbardziej ma sens i bardzo polecam w językach gdzie nie powoduje to narzutu. Natomiast zastąpienie dwóch intów strukturą przykładowo FilterCriteria jeszcze pewnie z jakimiś Optionalami pod spodem nie wnosi nic prócz dołożenia boilerplate do kodu który te metodę będzie wołał. Ani nie zwiększy

[Krolik]

@Hulleck123: przecież frameworki generują API wprost z sygnatury metody. Nie powinno mieć znaczenia czy tam jest obiekt czy dwa parametry.

[Hulleck123]

@Krolik: ale dla klienta, np aplikacji napisanej w angularze, już znaczenia ma. Niby nie duża zmiana, ale wymaga modyfikacji kolejnego komponentu.

[Krolik]

@Hulleck123: nie wiesz czy modyfikacja w ogóle będzie potrzebna. W większości przypadków nie jesteś w stanie przewidzieć w jakim kierunku będzie się rozwijać API, więc jedyną sensowną heurystyką jest robić wszystko możliwie najprościej i unikać komplikowania kodu tylko po to aby jakaś hipotetyczna zmiana w przyszłości była łatwiejsza. Bo to jest trochę jak kupowanie drugiej niepotrzebnej rzeczy w promocji tylko po to aby dostać trzecią niepotrzebną rzecz gratis. Nawet w tym

[Krolik]

@ly000: @Hulleck123: https://medium.com/swlh/stop-predicting-the-future-of-your-code-e0d403116f90