Metody statyczne - minusy

0

Siemka,

Niby wiadomo, że lepiej robić metody nie-statyczne niż statyczne, ponieważ w testach nie będzie można ich zamockować (a przynajmniej będzie o to trudno). Jednak co w przypadku utilów z metodami statycznymi w testach? Abstrahując już od tego, czy utile do testów są okej czy nie, co o tym sądzicie? Util w pakiecie testowym, sam w sobie nie będzie testowany. Czy zatem tworzenie mu metod statycznych nie niesie ze sobą żadnych przykrych niespodzianek i złych praktyk? Bo już się trochę zamotałem :D

@jarekr000000 @shalom @Koziołek @scibi92

1

Wszystko jest dla ludzi. Statyczne utile też. Ale prościej by się rozmawiało o konkretnym przykładzie :)
Jeśli chodzi o utile do testów, to jak najbardziej, szczególnie jeśli setup testów jest złożony. Ale zamiast staticów lepiej mieć jakiś sprytny fluent builder i mieć jakieś

TestConfiguration tc = TestConfiguration()
    .builder()
    .withX()
    .withY()
    .build();

someServiceWeAreTesting.someMethod(tc.someId());

tc.waitUntilStateChanged()
    .verifyA()
    .verifyB();
1

Jeśli masz pure function to może być static, bo wtedy i tak nie jest potrzebna żadna instancja, żeby coś wykonać
W testach pisz tak, żeby kolejnej osobie było łatwo przeczytać co test robi. Dużo tu zależy od przypadku

2

Trzaskaj te statiki jak kosmici dzidy laserowe.
Jak nie korzystasz z dziedziczenia - (bo nieładnie),
Jak nie korzystasz z mutowania ( bo nieładnie),
To
metoda statyczna od instancji niewiele się różni :-)

1

Na http://itshelf.net/ jest mój artykuł o tym co sądzę o kawowych utilsach - w bardzo stonowanym języku i trochę po angielsku.
Nie podlinkuję bezpośrednio bo jestem za firewallem.
Obecnie ten artykuł gdybym miał przepisać to byłby o wiele bardziej naszpikowany inwektywami.
Dodałbym może jeszcze hasło "utils nowym, powszechnie uznanym enterprajs singletonem".

Parafrazując przedmówcę:

  • jeśli masz utilsa w którym powtarza się jeden z argumentów - usuń statica
  • jeśli Twój utils ma jakieś pola a nie daj Boże mapę - pomyśl nad usunięciem statica
  • jeśli ten utils implementuje logikę biznesową - dlaczego w staticu?
1

@vpiotr: co jest złego w logice biznesowej w staticach?
Przecież metoda która ma static to po prostu jakaś operacja która nie wymaga żadnej instancji "pod sobą". Tak długo jak nie ma jakichś side-effects to wcale nie utrudnia testowania (ba, nawet ułatwia).

1
danek napisał(a):

@vpiotr: co jest złego w logice biznesowej w staticach?
Przecież metoda która ma static to po prostu jakaś operacja która nie wymaga żadnej instancji "pod sobą". Tak długo jak nie ma jakichś side-effects to wcale nie utrudnia testowania (ba, nawet ułatwia).

Logikę biznesową na staticach można podzielić na takie kategorie:

  • algorytmy uniwersalne (np. podaj płeć z PESELa, policz sumę IBANa)
  • czyste funkcje bez side effects z kilkoma parametrami (green field)
  • czyste funkcje bez side effects z 40 parametrami (faza maintainance)
  • czyste funkcje bez side effects z hash mapą jako argumentem (wystarczy jeden: "cache", "context", "session" - kod biblioteczny)
0

W javie chyba nie napisałem żadnego statica, nawet trywialnego od półtora roku, może dwóch -( nie dam sobie za to głowy obciąć, ale dość prawdopodobne).
Ale z drugiej strony nie mam żadnej reguły 'tylko nie statici'. Tak samo jakoś wychodzi. (DI to świnia - ciągle coś trzeba konstruować).

Z drugiej strony w takiej Scali - trzaskam bezwstydnie metody w object (taki singleton). W kotlinie to nawet robię zupełnie chamskie funkcje / static i to nawet bez klasy - horror. (Fakt, że nieczęsto, raczej w testach, ale jednak. Powód jest taki (miedzy innymi), że przez data class o wiele łatwiej uniknąć tej hashmapy z punktu 4 :-)

0
jarekr000000 napisał(a):

Z drugiej strony w takiej Scali - trzaskam bezwstydnie metody w object (taki singleton). W kotlinie to nawet robię zupełnie chamskie funkcje / static i to nawet bez klasy - horror. (Fakt, że nieczęsto, raczej w testach, ale jednak. Powód jest taki (miedzy innymi), że przez data class o wiele łatwiej uniknąć tej hashmapy z punktu 4 :-)

Nie znam Kotlina, ale data classy to uważam za dowód na to że nawet w bardzo ładnym kodzie OOP potrzebne są struktury danych (a nie "klasy"). Temat plącze się w Javie od dawna - DTO, Value Object, Lombok. Uważam że Kotlin poszedł w dobrą stronę.

A kotlinowskie "chamskie funkcje" to po prostu programowanie proceduralne. Przykład na to, że paradygmaty wcale nie muszą się wykluczać ani być lepsze jeden od drugiego.

1
vpiotr napisał(a):

A kotlinowskie "chamskie funkcje" to po prostu programowanie proceduralne.

No więc nie. Powinienem napisać był napisać czyste funkcje. Zamiast chamskie :-) Są one dużo dalej od programowania proceduralnego niż obiektówka.
Czyste funkcje nie używają statementów - cała funkcja to jedno wyrażenie.
Więc nawet nie ma miejsca na 'procedury`. Ale można się kłócić - to subiektywne wrażenie.

0
jarekr000000 napisał(a):
vpiotr napisał(a):

A kotlinowskie "chamskie funkcje" to po prostu programowanie proceduralne.

No więc nie. Powinienem napisać był napisać czyste funkcje. Zamiast chamskie :-) Są one dużo dalej od programowania proceduralnego niż obiektówka.
Czyste funkcje nie używają statementów - cała funkcja to jedno wyrażenie.
Więc nawet nie ma miejsca na 'procedury`. Ale można się kłócić - to subiektywne wrażenie.

Spoko. Może w Javie zbyt dużo takich czystych funkcji nie widziałem, ale widziało się trochę Lispa, więc rozumiem co nieco z tego co teraz napisałeś :-)

0
vpiotr napisał(a):
  • jeśli ten utils implementuje logikę biznesową - dlaczego w staticu?

Ale, że co.? Logika biznesowa w utilsach?

jeśli Twój utils ma jakieś pola a nie daj Boże mapę - pomyśl nad usunięciem statica

A w czym to przeszkadza ?

1 użytkowników online, w tym zalogowanych: 0, gości: 1