Czy metody mappera mogą być statyczne? Jakie widzicie potencjalne niedogodności ze statycznymi metodami w mapperach?
Dzięki!
- Rejestracja:ponad 5 lat
- Ostatnio:ponad rok
- Postów:131
0
edytowany 1x, ostatnio: Kiko88
AnyKtokolwiek
Mapper kogo / czego - mamy się domyślać jak dobry mąż?
- Rejestracja:ponad 6 lat
- Ostatnio:11 dni
- 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.
edytowany 1x, ostatnio: AnyKtokolwiek
- Rejestracja:ponad 6 lat
- Ostatnio:7 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 :)
- Rejestracja:ponad 12 lat
- Ostatnio:około godziny
- Postów:3561
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:
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 ...
edytowany 2x, ostatnio: wartek01
Dla mnie to świetny przykład na lambde. Ale faktycznie zdarzają się hiper duże mappery i wtedy najlepiej je gdzieś wypchnąć do klasy.
- Rejestracja:ponad 4 lata
- Ostatnio:około 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.