В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

Software Design/Architecture/Zen

1845 membersпожаловаться на группу
2020 October 07

a

atcq (Алексей)... in Software Design/Architecture/Zen
Дмитрий
вот всегда так. четкого ответа - почему все иммутабельным делать - никто дать не может. расплывчатые фразы какие-то. что где-то этот объект мутирует.
у роберта мартина в одной из книг это описано и он говорит только и исключительно о конкурентности и состояниях гонки, про упрощение понимания - ничего

хотя аргумент про упрощение мне вполне понятен
источник
10:53пожаловаться#1

˸A

˸̧̨ ͅBlack Akula˸̧̨ ... in Software Design/Architecture/Zen
Дмитрий
все кому не лень
Именно! Вам видимо не приходилось сталкиваться с такими монстрами, как collectTotals() в Magento
источник
10:53пожаловаться#2

AL

Anton Lakotka in Software Design/Architecture/Zen
Evgen
самый большой недостаток мутации - это тяжело отслеживать путь изменения данных
и это именно та самая причина
источник
10:53пожаловаться#3

R

Roman in Software Design/Architecture/Zen
Anton Lakotka
что тут понимать.
мутабельность -- это значит  fun foo(value: MutableValue) { value.bla = "secret" }
и такого говна должно быть как много меньше.
Скажем, есть User, который хочет сменить свой email. Подход с мутацией говорит сделать так так: self.email = new_email. Вы говорите, что это плохо. Подход с иммутабельностью говорит создать новый объект User, где будет другой email и им заменить старого юзера. Так чем концептуально эти два подхода различаются (не беря во внимание многопоточность), если в результате мы получим тоже самое?
источник
10:53пожаловаться#4

E

Evgen in Software Design/Architecture/Zen
Anton Lakotka
и это именно та самая причина
иммутабельность - много требует памяти
источник
10:55пожаловаться#5

AL

Anton Lakotka in Software Design/Architecture/Zen
у любого правила есть исключения.

но вцелом должна соблюдаться логичность кода:
val a = Foo("a")
println(a.value) //  "a"
someSimpleCheck(a)
println(a.value) // "b"


и если у тебя все сильно мутабельное и передается по ссылкам как любимом C/C++
то такой код крайне сложно читать
источник
10:57пожаловаться#6

AL

Anton Lakotka in Software Design/Architecture/Zen
и буквально после каждого вызова функции ты должен проверять что твой объект "не изменился"
источник
10:57пожаловаться#7

AL

Anton Lakotka in Software Design/Architecture/Zen
вот это все результаты "использования мутабельности неправильными руками"
источник
10:58пожаловаться#8

E

Evgen in Software Design/Architecture/Zen
Anton Lakotka
у любого правила есть исключения.

но вцелом должна соблюдаться логичность кода:
val a = Foo("a")
println(a.value) //  "a"
someSimpleCheck(a)
println(a.value) // "b"


и если у тебя все сильно мутабельное и передается по ссылкам как любимом C/C++
то такой код крайне сложно читать
Это нарушение принципа СОЛИД, а не проблема мутации
источник
10:58пожаловаться#9

DT

Dmitriy Tkachenko in Software Design/Architecture/Zen
Temporal coupling
источник
10:58пожаловаться#10

AL

Anton Lakotka in Software Design/Architecture/Zen
солид этого не запрещает
источник
10:58пожаловаться#11

R

Roman in Software Design/Architecture/Zen
Anton Lakotka
у любого правила есть исключения.

но вцелом должна соблюдаться логичность кода:
val a = Foo("a")
println(a.value) //  "a"
someSimpleCheck(a)
println(a.value) // "b"


и если у тебя все сильно мутабельное и передается по ссылкам как любимом C/C++
то такой код крайне сложно читать
Тут ты приводишь пример скорее супер кривого ООП, где не объект меняет своё состояние, а кто угодно. Протипоставление такого подхода — нормальное ООП, а не иммутабельность
источник
10:58пожаловаться#12

DT

Dmitriy Tkachenko in Software Design/Architecture/Zen
Значение в мутабельном объекте зависит от порядка вызова функций
источник
10:59пожаловаться#13

˸A

˸̧̨ ͅBlack Akula˸̧̨ ... in Software Design/Architecture/Zen
Evgen
иммутабельность - много требует памяти
https://en.m.wikipedia.org/wiki/Persistent_data_structure
Wikipedia
Persistent data structure
data structure that always preserves the previous version of itself when it is modified
источник
10:59пожаловаться#14

AL

Anton Lakotka in Software Design/Architecture/Zen
Roman
Тут ты приводишь пример скорее супер кривого ООП, где не объект меняет своё состояние, а кто угодно. Протипоставление такого подхода — нормальное ООП, а не иммутабельность
так ли?

правильное джава ООП этого не запрещает, то почему оно тогда кривое?

или если следовать твоей логике, то правильное ООП всегда иммутабельное?
источник
11:01пожаловаться#15

E

Evgen in Software Design/Architecture/Zen
Dmitriy Tkachenko
Значение в мутабельном объекте зависит от порядка вызова функций
А в иммутабельном разве порядок не важен?
источник
11:02пожаловаться#16

DT

Dmitriy Tkachenko in Software Design/Architecture/Zen
Evgen
А в иммутабельном разве порядок не важен?
Если значение не меняется а создаётся новое всегда - подумай сам
источник
11:02пожаловаться#17

AL

Anton Lakotka in Software Design/Architecture/Zen
Evgen
А в иммутабельном разве порядок не важен?
не важен
источник
11:02пожаловаться#18

E

Evgen in Software Design/Architecture/Zen
Anton Lakotka
не важен
результат то будет отличаться - что значит не важен?
источник
11:03пожаловаться#19

AL

Anton Lakotka in Software Design/Architecture/Zen
two() + three() -- важен ли порядок в котором функции two или three выываются?
источник
11:03пожаловаться#20