Metody immutable na przykładzie sortowania

0

Jak to robić lepiej, tak:


foo do() {
    // ...
    list = sortMyList(new ArrayList(list), comparator);
    // ...
}

List sortMyList(List list, Comparator comparator) {
    return Collectors.sort(list, comparator);
}

czy tak:


void foo do() {
    // ...
    list = sortMyList(list, comparator);
    // ...
}

List sortMyList(List list, Comparator comparator) {
    list = new ArrayList(list);
    return Collectors.sort(list, comparator);
}

0

Co to jest metoda immutable? Chodzi ci o metody bez skutków ubocznych może? Wszystko zależy od sytuacji, ale generalnie dużo prościej analizuje się i używa kod który nie zmienia swoich argumentów, bo np. dzięki temu automatycznie wszystko jest thread safe.

0

Tak, chodzi mi o podejście funkcyjne, żeby było tak jak w R, że jak chcę x posortować to nie robię sort(x) tylko x = sort(x)

0

Moim zdaniem, ani tak, ani tak. Np. z tego powodu, o którym @Shalom pisał, tj. modyfikacja parametrów wejściowych, które potem zwracamy. Nawet w "Clean Code" jest napisane "Output arguments should be avoided" i właśnie o to chodzi. Druga sprawa to fakt, że w normalnym projekcie nie powinno się robić takich one-linerów jak te w załączonych przykładach, bo to nic nie wnosi i tylko zaciemnia kod oraz utrudnia jego analizę (z drugiego przykładu też da się zrobić one-liner). Musiałbyś doprecyzować problem albo podać bardziej konkretny przykład, jeżeli chcesz uzyskać inną odpowiedź.

0

serio metody po 1 linijkę są złe? Przecież w clean codzie pisali, że tak ma być... Twórca ggplota w R, prezes RStudio całe pakiety tak pisze z funkcjami po 1-2 linijki

0

Mylisz kod 1 linijkowy z kodem 3 linijowym wcisnietym w 1 linie

0

aha, chodzi o to, że zamiast

list = sortMyList(new ArrayList(list), comparator);

powinienem pisać:

list = new ArrayList(list);
list = sortMyList(list, comparator);
0

Ogólnie napisałem, nie do konkretnego przykładu. A co do pytania to ja już bym bardziej widział coś typu

list = list.sort(comparator)
0

Chwila chwila,
list = sortMyList(list, comparator);

to nie jest po prostu:
Collectors.sort(list, comparator);
?

Jeśli chcesz żeby mieć immutable to:
List newList = new Arraylist(list);
Collectors.sort(newList, comparator);

Gdybym w kodzie zobaczył:
list = sortMyList(list, comparator);
albo
list = sortMyList(new ArrayList(list), comparator);
to bym wietrzył spisek.

0

nie, to jest troche bardziej skomplikowane... nie chce mi się dopisywać całego kodu... ani wymyslac innych przykładów.
W moim sortowaniu używam Pageable, Collatorów, relfeksji i jeszcze wszystko zapętlam tak by można było podać kilka comparatorów naraz.

A co sądzicie o takim czymś:

void mainMethod {
    MyData data;
    // ...
    // ...
    // ...
    data = process(data.iterator);
}

MyData process(Iterator it) {
    List myList = // ... zamiana it na listę
    return process(myList);
}

MyData process(List list) {
    MyData result = // ...
    return result;
}

czy ma to sens czy lepiej tak:

void mainMethod {
    MyData data;
    // ...
    // ...
    // ...
    Iterator it = data.iterator;
    List myList = // ... zamiana it na listę
    data = process(myList);
}

MyData process(List list) {
    MyData result = // ...
    return result;
}
1

Po prostu nie używaj java.util. tylko zobacz pakiet /biblioteke vavr.io. Listy i inne struktury w vavr są niemutowalne.
Zero zaskoczeń, zero mutantów.
(java.util w typowym kodzie biznesowym nie powinno sie stosować, chyba że ktoš lubi wpuszczać subtelne bugi na produkcje).

1

Pytanie zasadnicze: dlaczego nie korzystasz ze strumieni?

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