Statyczne metody w mapperach

Czy metody mappera mogą być statyczne? Jakie widzicie potencjalne niedogodności ze statycznymi metodami w mapperach?
Dzięki!

Kiko88 napisał(a):

Jakie widzicie potencjalne niedogodności ze statycznymi metodami w mapperach?

Takie jak zawsze. Mała podatność na OOP.

Kiko88 napisał(a):

Czy metody mappera mogą być statyczne?

Mogą. Można też pisać brzydki kod. Prawo nie zabrania

Jakie widzicie potencjalne niedogodności ze statycznymi metodami w mapperach?

Mówiąc precyzyjniej niż @AnyKtokolwiek, statyczne metody nie są polimorficzne. No, ale nie zawsze polimorfizm potrzebujemy. Podaj przykład kodu to będzie nam prościej :)

Jeszcze do Javy 8 raczej mappery trzymałem w klasach. Od Javy 8 nie ma żadnego powodu, żeby nie trzymać mapperów jako metod statycznych bo taki klasyczny mapper bez efektów ubocznych to przecież nic innego jak funkcja mapująca, a sam mapper jeśli jest przekazywany to powinien być przekazywany jako strategia mapowania:

interface Mapper<T, R> extends Function<T, R>, Serializable { } // można nawet ten interfejs olać i używać Function<T, R>

class Mappers {
    
    public static String intToString(final Integer integer) {
        return integer == null ? "null" : integer.toString();
    }
    
    // Jakieś inne mapowania
}

class MyClass {
    private final Mapper<Integer, String> mapper;

    public MyClass(final Mapper<Integer, String> mapper) {
        this.mapper = mapper;
    }
}

class Test {
    
    // Użycie
    MyClass myClass = new MyClass(Mappers::intToString);
}

To zadziała w 90% przypadków. Czasami jednak zdarzają nam się "ważniejsze" mappery (np. takie ze stanem) - wtedy można tworzyć konkretne klasy i implementacje interfejsów.
Jeśli chodzi o polimorfizm to w przypadku mapperów bardzo rzadko spotyka się, żeby był potrzebny więc raczej bym olał.

Jeśli chodzi o wykorzystywanie bezpośrednie funkcji mapującej, tj.

String value = Mappers.intToString(someInt); 

to też jest OK pod warunkiem, że ma to być niezmienne, istnieje i będzie istniał jeden taki mapper na aplikację lub widoczność funkcji jest mocno ograniczona. Problem się zacznie jeśli będziesz miał w tej samej klasie intToString1 , intToString2 , intToString3 ...

Takie jak zawsze. Mała podatność na OOP.

Tyle że OOP nie jest wszędzie potrzebne. W Kotlinie możesz stworzyć plik .kt który bedzie zawierał funkcje (producedury) bez klasy. W realnym świecie robienie czegoś 100% na siłe obiektowego jest bez sensu. Problem można by częściowo rozwiazać gdyby było coś takiego jak method extension w Javie, ale niestety nie ma.