.
вместо того чтобы просто вернуть гребанный список
Size: a a a
2020 May 24
DK
да
DK
Это правило иммутабельности
DK
Нужно создавать новый объект и копировать в него данные из старого.
.
а чем чреват возврат старого объекта?
Ю
Аа ну да иначе это уже дичь будет )
Ю
а чем чреват возврат старого объекта?
Он будет постоянно увеличиваться
Ю
Приведите пример этого гетЛиста
ДЧ
а чем чреват возврат старого объекта?
Тем, что его можно изменить
DK
Если у вас однопоточное приложение, то мутабельность объектов не так важна, но если есть несколько потоков, то объект может быть изменен одним потоком в промежутке между операциями проведенными другим потоком.
.
public List<Integer> getList() {
ArrayList<Integer> a = new ArrayList<>();
a.addAll(list);
return a;
}
ArrayList<Integer> a = new ArrayList<>();
a.addAll(list);
return a;
}
.
Тем, что его можно изменить
я думал метод всегда будет ссылаться на актуальный список
Ю
public List<Integer> getList() {
ArrayList<Integer> a = new ArrayList<>();
a.addAll(list);
return a;
}
ArrayList<Integer> a = new ArrayList<>();
a.addAll(list);
return a;
}
Ну list изменяться будет
Ю
я думал метод всегда будет ссылаться на актуальный список
В случае с рандом там якобы нужен новый список
ДЧ
я думал метод всегда будет ссылаться на актуальный список
Так вопрос в том, что потребитель может изменить значение, и это не ожидаемое поведение, как правило, а наоборот нежеланное
E
Добрый день! Подскажите, как бороться с таким вот?
E
javafx - учебный проект
E
ругается на добавление в listView новых сообщений - не вылетает и не крашится, но ошибка глаза мозолит
СШ
ругается на добавление в listView новых сообщений - не вылетает и не крашится, но ошибка глаза мозолит
Добавляешь неправильно
E
Добавляешь неправильно
я уже разобрался - там надо было воткнуть Platform.runLater(() -> {}); обернуть любое добавление в listView