из глубокого покажу ситуации что объект имутабельный не является имутабельном в случае если принимает хоть одно мутабельное свойство

и покажу такой пример)

ну и объясню соответственно а как вывод просто подвиду под сложность, что сложна жить когда объект меняется

особенно в много поточных система с конкаренси, но и в пхп без этого тоже вносит некую сложность)

особенно в много поточных система с конкаренси, но и в пхп без этого тоже вносит некую сложность)

пфф... ты это в чате по PHP пишешь)

введи понятие "стэйт"

да стейт в самом начале введу

в определение объект

а еще дай отсылку на goto considered harmful

объект это состояние и методы над этим состоянием и все это описано в классе

http://david.tribble.com/text/goto.html

объект это состояние и методы над этим состоянием и все это описано в классе

не, стэйт надо рассматривать отдельно

я там не глубоко почти без подготовки

а объект - мне тут нравится аналогия Грэга Янга - что мол это такой маленький комьютер. со своей изолированной памятью где он хранит стэйт и работает с ним.

вон я выше это примерно и написал)

настолько примерно что нет

мб мб

смотри, с аналогией с комьютерами - представь что у тебя все объекты в системе общаются по сети. И реально один объект - это комьютер

отсюда следует что геттеры/сеттеры - неэффективно потому что тебе придется передавать "по сети" большое количество данных. И это как бы плохо с точки зрения изоляции

но теперь надо объяснить людям что такое изоляция

"изоляция это когда у тебя есть что-то внутри и что-то снаружи. И то что снаружи не влияет на то что внутри и наоборот".

нельзя в определение терминов употреблять другие термины объяснение которых ты не дал

а ну ясно с таким объяснением

тогда имутабельность это неизменность объекта, а мутабельнсоть изменяемость объект, конец

фактически это уже не относится к имутабельности так что пофиг

мне просто не нравится когда объекты объясняют при помощи "классов". Это просто кейворд в языке программирования и не более

мне просто не нравится когда объекты объясняют при помощи "классов". Это просто кейворд в языке программирования и не более

согласен

объект это состояние и методы по работе с этим состоянием

а то что оно в пхп или java сделано через классы

объект это состояние и методы по работе с этим состоянием

слово "методы" заменить на "поведение"

да методы = поведение в целом одно и тоже

в этом примере

есть объект "дверь", у нее есть состояние - открыта или закрыта. Есть поведение - ее можно открыть и закрыть. А теперь сделай мне имутабельную дверь

если раньше было setState ($newState) то теперь open(), close()

поведения

если раньше было setState ($newState) то теперь open(), close()

оно и раньше было open и close

и возможно даже возвращало бы сама себя

есть объект "дверь", у нее есть состояние - открыта или закрыта. Есть поведение - ее можно открыть и закрыть. А теперь сделай мне имутабельную дверь

Final?

Final?

что final?

ты про java-ский final?

сергей существует огромное количество доказательств что ооп не особо пригоден для реального мира, потому что все попытки загнать реальный мир в ооп жестоко разваливались

что final?

final class Door { ... }

но реальный мир хорош с точки зрения демонстрации ооп

final class Door { ... }

+

сергей существует огромное количество доказательств что ооп не особо пригоден для реального мира, потому что все попытки загнать реальный мир в ооп жестоко разваливались

объекты представляют объекты реального мира. Мне тут нравится аналогия дяди боба - адвокаты в бракоразводном процессе представляют мужа и жену. Но они не должны быть мужем и женой.

final class Door { ... }

причем тут имутабельность?

при том что если если ты сделаешь дверь имутабельной

кто то расширит твой класс

и сделает setState

кто то расширит твой класс

и сломает LSP

ну поэтому не юзайте protected

и новый класс станет не имутабельным

наследование НИКАКОГО отношения не имеет к мутабельности. Просто делаешь весь стэйт protected

и сломает LSP

да почему же

наследование НИКАКОГО отношения не имеет к мутабельности. Просто делаешь весь стэйт protected

private )

вполне возможно что и нет

да почему же

офигеть, у тебя поведение двери раньше не меняло стэйт а теперь меняет

как по мне - это нифигенское такое изменение в поведении

я серег этот пример покажу на видео

private )

пардон

там еще приколы есть языка как можно по тролить

если раньше возвращался новый объект с новой ссылкой, а теперь старый, то вы вероятно много где все поломали

ну то есть я к чему - ты говоришь что "не хочешь уходить в глубь", но при этом тащищ наследование

то мне кажется получится каша

возможно(

давай обсудим после того что я расскажу как я считаю

оке

ERROR: S client not available

я действительно рад был бы обсудить)

я пример с дверью покажу

можешь любой другой пример. Просто интересно было бы показать два примера - один где имутабельность более чем логична, и пример где работа со стэйтом может казаться проще

вот это очень хотел

но ничего простого придумать не смог

а кто говорил что будет легко?)

чтобы не было такова что имутабельность это супер мутабельнсоть это фи

final class Door { private $state; public function __construct($state) { $this->state = $state; } public function getState() { return $this->state; } } Я это имел в виду. И да, это пыха. Вполне себе иммутабельно. Если не долбануть сюда сеттер, конечно.

вот я не могу придумать кейс когда имутабельность на вид сложнее но по факту намного проще.

да она всегда упрощает

да она всегда упрощает

ну не скажи

кстате надо ли пример с имутабельной дверью все еще

я кажется понял что ты хотел от меня увидеть)

попробуй запилить проект с использованием event sourcing. Я сильно сомневаюсь что ты будешь делать имутабельными вещи вроде "записей в блоге"

final class Door { private $state; public function __construct($state) { $this->state = $state; } public function getState() { return $this->state; } } Я это имел в виду. И да, это пыха. Вполне себе иммутабельно. Если не долбануть сюда сеттер, конечно.

без final тоже имутабельно

нее

там есть фишка определенная)

я это в конце покажу

нее

что не? тащишь наследование - тогда изволь рассказать про контракты, прекондишены, инварианты и посткондишены, а так же про LSP

там еще можно Multiply call constructor сделать)

что не? тащишь наследование - тогда изволь рассказать про контракты, прекондишены, инварианты и посткондишены, а так же про LSP

формально объект куда раньше передавалась дверь

будет принимать и новый объект

с точки зрения кода он не будет юзать новые методы

поэтому изменения состояния он делать не будет

это нарушение lsp

а в новом объекте могут быть новые методы которые могут сменить состояние

$openedDoor = Door::open(); $closedDoor = $openedDoor->close(); $openedAgainDoor = $closedDoor->open(); assert($closedDoor !== $openedAgainDoor);

попробуй переопределить так что бы дверь стала снова мутабельной и при этом ассерт отработал

если ты сломал посткондишены - то это явно говорит о нарушении LSP

$openedDoor = Door::open(); $closedDoor = $openedDoor->close(); $openedAgainDoor = $closedDoor->open(); assert($closedDoor !== $openedAgainDoor);

Door::opened() наверн :)

да

попробуй переопределить так что бы дверь стала снова мутабельной и при этом ассерт отработал

сейчас