k
Что-то не могу понять, как в лямбде this заменить, чтобы была ссылка на Inner класс, как это было бы в случае с Anonymous class?
Size: a a a
2020 October 11
QH
Что-то не могу понять, как в лямбде this заменить, чтобы была ссылка на Inner класс, как это было бы в случае с Anonymous class?
Никак, у лямбд нет this.
k
я имею ввиду, есть ли какой нибудь эквивалент?
k
ну кроме того, как создать переменную
k
и туда лямбду сунуть
k
ну ладно, пускай так будет
QH
Анонимный класс
T
Лямбда внутри себя вообще тип функционального интерфейса, на который промэпится, не знает. Он устанавливается по окружающему контексту. Если бы был доступен this, это бы не работало. Если this нужен, лучше вернуться к анонимному классу
S
Что-то не могу понять, как в лямбде this заменить, чтобы была ссылка на Inner класс, как это было бы в случае с Anonymous class?
Closure не будет достаточно?
S
Что-то не могу понять, как в лямбде this заменить, чтобы была ссылка на Inner класс, как это было бы в случае с Anonymous class?
Покажи пример кода, и что хочется получить в итоге.
a
старшие товарищи, есть такая ситуация:
Есть класс
так вот такой вопрос, как лучше поступить: изменить существующий объект или лучше пометить поле как
просто не совсем ясно уместна ли здесь иммутабельность (которая вроде по дефолту лучше мутабельности)
Есть класс
class Product и, допустим, поле String name, которое можно изменитьтак вот такой вопрос, как лучше поступить: изменить существующий объект или лучше пометить поле как
final и вернуть новый объект?просто не совсем ясно уместна ли здесь иммутабельность (которая вроде по дефолту лучше мутабельности)
Используя иммутабельность, ты автоматом получаешь отсутствие большого количества потенциальных граблей. Конкарренси, тестирование, сложное поведение кода из-за большого количества состояний объектов, потенциальные npe и т. д. Иммутабельность практически всегда должна быть по умолчанию. Мутабельность должна быть обоснована (например, проведением замеров и проблемами с перформансом и ясным пониманием, что причина - создание лишних объектов именно в этом месте, что практически никогда не так).
S
alexme951
Используя иммутабельность, ты автоматом получаешь отсутствие большого количества потенциальных граблей. Конкарренси, тестирование, сложное поведение кода из-за большого количества состояний объектов, потенциальные npe и т. д. Иммутабельность практически всегда должна быть по умолчанию. Мутабельность должна быть обоснована (например, проведением замеров и проблемами с перформансом и ясным пониманием, что причина - создание лишних объектов именно в этом месте, что практически никогда не так).
+1
СЕ
окей там просто кто то сегодня скидывал (не мне) ссылку на этот канал, в описании "Чат для начинающих и не только" поэтому решил сначала сюда написать. Тогда прошу прощения (удалил что бы не мешало)
af
чем больше стараюсь вникнуть в эту сферу (java разработка) тем больше новых непонятных терминов узнаю.
и это очень сильно отталкивает.
Как побороть эту лень?
и это очень сильно отталкивает.
Как побороть эту лень?
af
настолько это ли сложно, как это представляю я?
D
askjar fhnj
чем больше стараюсь вникнуть в эту сферу (java разработка) тем больше новых непонятных терминов узнаю.
и это очень сильно отталкивает.
Как побороть эту лень?
и это очень сильно отталкивает.
Как побороть эту лень?
Сколько тебе лет?
AA
Сколько тебе лет?
Вот именно, вместо того, чтобы писать - разглагольствует😁
D
Просто по всей истории сообщений выглядит так, что ты либо школьник, либо вообще ребёнок
D
И умоляешь убедить других тебя начать хоть что-то делать