модель зависящая от хранения

ты можешь бизнес логику вынести в доменную сущность которая будет хранить данные внутри ar моделек

модель зависящая от хранения

модель данных

ок )

class User { /** * @var UserDataModel */ private $userData; }

вот о чем я

> Или, можно взять все, что есть в языке и назвать это объектами как по мне это более чем валидно

это ли имел ввиду Алан Кей?)

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

это ли имел ввиду Алан Кей?)

не уверен... он точно говорил что "но я не имел ввиду C++"

вообщем ООП головного мозга наверно также плохо как и ФП головного мозга и подобного)

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

Об этом Вэст вещает в своих речах... мол что ФП это просто очередной виток очевидной идеи об изоляции побочных эффектов

тип тренд ФП с монадами и т.д. это лишь повторение того что подразумевалось под ооп

вообщем ООП головного мозга наверно также плохо как и ФП головного мозга и подобного)

почитай письмо Дэйкстры

что бы понять предпосылки появления всего этого булшита

то самое которое goto considered harmful

что именно Дэйкстры почитать

мне нравиться как он пишет он норм мужик)

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

вот тут с пояснениями и разбором мыслей

это про ненависть к goto ?

это объяснение проблемы с goto

про сложность верификации такой программы

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

это про ненависть к goto ?

Here Dijkstra observes that humans are better at visualizing static relationships than dynamic relationships. Thus, he argues, we should minimize the difference between the two when expressed as program code, so that the dynamic (nonconstant) aspects of the program are evident in the structure of the source code itself.

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

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

только это какой-то дискашен на тему

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

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

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

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

хм, а что может быть интересного в том что гото гавно?) вроде же это аксиома, давно же решили так умные дядьки

хм, а что может быть интересного в том что гото гавно?) вроде же это аксиома, давно же решили так умные дядьки

То, что это не аксиома?

То, что это не аксиома?

ну я хотел сказать, что гото это же что-то мертвое, с чем никогда не встретишься

ну я хотел сказать, что гото это же что-то мертвое, с чем никогда не встретишься

И почему так?

И почему так?

ну я не говорю, что плохо это читать, просто интересуюсь, какой с этого профит? Скажем так, меня это удивило. А плохо, никогда не думал на эту тему, но наверно потому, что несёт путаницу.

ну я не говорю, что плохо это читать, просто интересуюсь, какой с этого профит? Скажем так, меня это удивило. А плохо, никогда не думал на эту тему, но наверно потому, что несёт путаницу.

ОО возникло не на пустом месте, всему были причины.

Их понимать надо для того, чтобы яснее понимать принципы, когда что-то стоит делать, а когда не стоит

scala норм, если проникнуться... но мне больше kotlin нравится

котлин, да, он дружелюбнее как-то

Их понимать надо для того, чтобы яснее понимать принципы, когда что-то стоит делать, а когда не стоит

вот и ответ на мой вопрос, спасибо

ну я не говорю, что плохо это читать, просто интересуюсь, какой с этого профит? Скажем так, меня это удивило. А плохо, никогда не думал на эту тему, но наверно потому, что несёт путаницу.

интересный факт. То письмо не совсем про goto

ну тоесть 90% информации описывает почему вообще такие штуки не очень хорошо. Не конкретно goto а почему вообще нам надо писать код по другому. ПОнимание этого позволит тебе лучше понять себя.

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

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

можно, но это потолок

насколько бредовой выглядит идея сделать все модели immutable? а сеттеры заменить на что-то вроде withProperty('new value'): self

@fes0r Сергей ^

насколько бредовой выглядит идея сделать все модели immutable? а сеттеры заменить на что-то вроде withProperty('new value'): self

хм, а что это хорошего даст в данном случае?

не знаю. пытаюсь понять возможные последствия для архитектуры

Сеттеры или их замена плохо)

я почитал про CQRS у Фаулера

вроде как это связанные вещи

Именно так и выглядят ValueObjects

но все равно не понятн

имхо это может дать плюсы в много поточной среде

я почитал про CQRS у Фаулера

в моем понимании оно про то, что в некоторых случаях (ээээ "доменах предметной области") отображение/чтение и изменение данных происходят существенно разным образом. в С++ к примеру у каждого класса потенциально имеется ДВА интерфейса - для чтения и для записи.

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

в случае с пхп большого профита врятли стоит ожидать

имхо это может дать плюсы в много поточной среде

у меня нет многопоточности, я говнокодер на пхп

я написал имхо

с точки зрения "модель только для чтения" - это immutable модель

имутабельность еще хороша в js в асинхронности

в которой за бонус скорости и асинхронности ты платишь памятью

python весь immutable

ну "почти весь"

реакт вон на js тоже на этом базируется под копотом, говорят)

имхо в php лучше оставить ValueObject а вот всякие сервисы вполне не плохо делать без side эффектов

типо имутабельные, на самом деле не делать сэтеров и все передавать аргументами в метод)))

ну и пару зависимостей в конструктор которые точно используются почти всегда)

это опять же имхо

типо имутабельные, на самом деле не делать сэтеров и все передавать аргументами в метод)))

в конструктор?

например UserService

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

по username, password и тд это аргументы метода

а вот работать с бд, это в конструкторе, туда или pdo, или entityManager в зависимости от того что в приложение используется

понял

это мое имхо

не факт что правильное

т.е. получается просто соглашение, не жестко заданные правила

компромис скорей)

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

теперь я не понял

ага я тоже, перестал понимать)

как оно после этого immutble?