Statyczne metody w mapperach

Statyczne metody w mapperach
K8
  • Rejestracja:ponad 5 lat
  • Ostatnio:ponad rok
  • Postów:131
0

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

edytowany 1x, ostatnio: Kiko88
AK
Mapper kogo / czego - mamy się domyślać jak dobry mąż?
AK
  • Rejestracja:prawie 7 lat
  • Ostatnio:około miesiąc
  • Postów:3561
1
Kiko88 napisał(a):

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

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


Bo C to najlepszy język, każdy uczeń ci to powie
edytowany 1x, ostatnio: AnyKtokolwiek
KamilAdam
  • Rejestracja:ponad 6 lat
  • Ostatnio:29 dni
  • Lokalizacja:Silesia/Marki
  • Postów:5505
1
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 :)


Mama called me disappointment, Papa called me fat
Każdego eksperta można zastąpić backendowcem który ma się douczyć po godzinach. Tak zostałem ekspertem AI, Neo4j i Nest.js . Przez mianowanie
K8
Bardziej się na razie zastanawiam kiedy ma sens używanie statycznych mapperów.. Taka refleksja mnie naszła ;) Dzięki za odp.
W0
  • Rejestracja:ponad 12 lat
  • Ostatnio:około 5 godzin
  • Postów:3586
2

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:

Kopiuj
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.

Kopiuj
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 ...

edytowany 2x, ostatnio: wartek01
YourFrog2
Dla mnie to świetny przykład na lambde. Ale faktycznie zdarzają się hiper duże mappery i wtedy najlepiej je gdzieś wypchnąć do klasy.
S9
  • Rejestracja:ponad 4 lata
  • Ostatnio:ponad 2 lata
  • Lokalizacja:Warszawa
  • Postów:1092
4

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.


Zarejestruj się i dołącz do największej społeczności programistów w Polsce.

Otrzymaj wsparcie, dziel się wiedzą i rozwijaj swoje umiejętności z najlepszymi.