Metoda statyczna w klasie, które jest SpringBootowym beanem.

Hej,

mam sobie w swoim projekcie serwis @Service, który jest wstrzykiwany w kilka innych serwisów. Do tej pory wszystko było klarowne, ale dodałem pewien feature, w którym nie ma potrzeby wszystkich klas mianować beanami. We wspomnianym wczęsniej serwisie jest jedna metoda, która przydaje mi się w niektórych miejscach w klasach związanych z nowym ficzerem.Metoda ta jest niezależna od stanu całej klasy, wobec czego aż się prosi, żeby przekształcić ją na metodę statyczną. Boję się jednak, że jest coś o czym nie wiem, a czego będe ponosił konsekwencje. Obecnie wołam ta metodę tworząc obiekt tej klasy-serwisu, ale pzez new i na obiekcie ją wywołuję. Strasznie mnie to jednak kłuje w oczy. Na tyle mocno, że postanowiłem zaczerpnąć tutaj porady.

Stanie się coś, jeśli zrobię ją static i zamiast tego zasranego new po prostu ją wywołam jak metodę statyczną?

1. Nie SpringBootowym, a springowym.
   S.Boot to tylko narzędzie do startu i automagicznej konfiguracji

2. Co to za metoda, przykład.
   Mam przeświadczenie, że da się to stylowo obiektowo napisać, ale ty ukrywasz. Np zmieniając czasownik na obiekt "odczaswonikwy" itd ...

Gdy springoza wejdzie za mocno.
Pewnie nic się nie stanie. Na pewno nic się nie stanie, jeśli jak człowiek cywilizowany wydzielisz to do osobnej klasy (np. Helper/Util) zamiast na siłę wpychać ten kawałek kodu do serwisu, gdzie widać jasno, że nie powinien tam być.

Oboje macie racje - przeglądnąłem tą karykaturę serwisu i tak naprawdę prosił się o przeróbkę na klasę utilową - co właśnie robię. Cóż, metoda gumowej kaczki jak zawsze skuteczna :) Dzięki za reakcję, wracam do przerabiania tego gówna na nieco bardziej sensowny kod :)

Nic się nie stanie. Jeżeli masz funkcję znaczy metodę statyczną, to nie ma co na siłę robić jej "obiektowej". Ogólnie takie podejście wali na kilometr XX wiecznymi podręcznikami Javy. Inna sprawa, to czy koniecznie powinna być częścią Beana, bo ten akurat jest obiektem i metody klasy to nie koniecznie coś, co do niego pasuje.

piotrpo napisał(a):

Nic się nie stanie. Jeżeli masz funkcję znaczy metodę statyczną, to nie ma co na siłę robić jej "obiektowej". Ogólnie takie podejście wali na kilometr XX wiecznymi podręcznikami Javy. Inna sprawa, to czy koniecznie powinna być częścią Beana, bo ten akurat jest obiektem i metody klasy to nie koniecznie coś, co do niego pasuje.

No właśnie nie chciałem forsować w głupkowaty sposób obiektowości tam, gdzie nie była ona potrzebna. Koniec końców przerobiłem cała klasę na typowego Utila, bo może pierwotnie nadawała się ona na serwis, to po kilku refaktorach, w obecnej formie zdecydowanie mijało się z celem trzymanie jej dalej jako serwis. Korzystanie z niej jak z utila jest teraz wygodniejsze i schludniejsze.

@Belka:

Ma stałą / zmienną implementację?
Bo zmienność, zbieżna ze zmiennością Servicu, to mógłby być argument, aby tam rezydowała. Zmienia się wspólnie (lub "wspólnie") z zasadą pracy Service??

W każdym innym przypadku utils.

ZrobieDobrze napisał(a):

@Belka:

Ma stałą / zmienną implementację?
Bo zmienność, zbieżna ze zmiennością Servicu, to mógłby być argument, aby tam rezydowała. Zmienia się wspólnie (lub "wspólnie") z zasadą pracy Service??

W każdym innym przypadku utils.

Kiedyś była nieco bardziej rozbudowana, teraz wiele rzeczy zostało porozdzielanych, zezłomowanych etc. Hmmm, obecne funkcje mógłbym porównać do czegoś w stypu pobierania aktualnej daty sformatowanej według jakiegoś patternu. Util jak byk, ale zmyliło mnie to, że było tam jeszcze kilka innych metod, które jak się okazało po głębszej (ofc bez przesady) analizie, były uzywane w testach, toteż IJ nie wyszarzał ich jako usued. Większość poszła do piachu, a metody bezstanowe, kompletnie niezależne od potencjalnego egzemplarza tejże klasy zostały zadeklarowane jako static.