Мы тут за software design вообще-то :|

если бы так было всегда

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

он говорит, что это лучший метод, который он нашел при работе с C#

и это странно)

и это странно)

ну так то да, хотя он вроде это говорил только про штуки типа сервис отправки email-ов

но не уверен

но если у него интерфейсы через IUsers то возможно повреждение мозга

мне как бы его мнение относительно ООП не особо интересно)

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

ты ж в C# при таком подходе теряешь возможность делать полиморфные методы…

и получается процедурщина обычная

но если у него интерфейсы через IUsers то возможно повреждение мозга

ну это ж сишарпщики, у них так принято...)

и получается процедурщина обычная

раз ты такой умный - сходи и выступи на NDC с какой-нибудь темой "ООП это не только процедуры и данные"

сперва добейся, да(

p.s. он вообще-то там говорил что "но вообще-то это не совсем ООП бла бла" но я в упор не понимаю почему тогда он приводит именно такие примеры

возможно что бы усилить эффект что "ФП лучше!"

или упростить что-нибудь

а пример совсем ооп, где active record это норм?

а пример совсем ооп, где active record это норм?

я походу промотал этот кусок

ну т.е. совсем ооп это active record, ddd эванса это анемичные модели, а единственный вариант юзать c# это юзать менеджеры

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

да вообще ничего не важно)

в целом да

ну т.е. совсем ооп это active record, ddd эванса это анемичные модели, а единственный вариант юзать c# это юзать менеджеры

короч да, фп однозначно лучше)

noop

Моя любимая парадигма

ну т.е. совсем ооп это active record, ddd эванса это анемичные модели, а единственный вариант юзать c# это юзать менеджеры

Расскажи как правильно, а все что я видел в проде это и были пляски с сервисами вокруг pojo, на всех проектах. И чем больше интерфейсов/индирекшен-вызовов - тем лучше

Расскажи как правильно, а все что я видел в проде это и были пляски с сервисами вокруг pojo, на всех проектах. И чем больше интерфейсов/индирекшен-вызовов - тем лучше

ты же вкурсе про штуки типа whole value и т.д.? ну мол когда ты поведение хранишь там где стэйт для этого поведения. и стэйт дробиться под поведение а не под "не ну а шо, оно ж все про юзера, все туда и положу"

вот если бы еще сообщения были а не вызовы процедур....

Расскажи как правильно, а все что я видел в проде это и были пляски с сервисами вокруг pojo, на всех проектах. И чем больше интерфейсов/индирекшен-вызовов - тем лучше

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

ну т.е. почему бы не делать ровно так, как он предлагает делать в f#: берем UserManager и переносим все его методы в User, а там где нужны зависимости - передаем их(конечно желательно за интерфейсами, дабл диспатчи и все такое) как аргументы в конкретный метод

ну т.е. почему бы не делать ровно так, как он предлагает делать в f#: берем UserManager и переносим все его методы в User, а там где нужны зависимости - передаем их(конечно желательно за интерфейсами, дабл диспатчи и все такое) как аргументы в конкретный метод

ну или потом можно совсем фпшно - метод вашего pojo будет возвращать Event[], которые можно процессить)

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

в Java вообще муть с терминологией. Насколько я помню необходимость в термине POJO появилась изза бобов, которые накладывали свои ограничения (типа должно уметь сериализацию).

ну то есть pojo - просто класс без ограничений и требований. Делай что хочешь и как хочешь. В том числе нормальное ООП.

да-да, pojo это без наследования от EntityBean

или как его там

проще говорить что bean это pojo с наследованием от entity bean (или атрибутом)

ну мол, любой класс это pojo но не любой pojo это bean

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

тип того, маркетинг такой маркетинг)

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

а что по доменом сейчас подразумеваете? ?

а что по доменом сейчас подразумеваете? ?

предметная область

а что по доменом сейчас подразумеваете? ?

https://ru.wikipedia.org/wiki/%D0%94%D0%BE%D0%BC%D0%B5%D0%BD

с2 иногда невозможно читать - сплошные отсылки

с2 иногда невозможно читать - сплошные отсылки

щито поделать

осталось только понять, почему они плюсы называют CeePlusPlus :D но это так, оффтопик

насколько понял про double dispatch - это фактически перевод рантайм проверки типов в компайл-тайм (и ужесточение оной тем самым) или что-то я не то понял?

осталось только понять, почему они плюсы называют CeePlusPlus :D но это так, оффтопик

помню у нас в универе препод по 1С говорил что если кто то скажет адин Цэ тому пиздец))

насколько понял про double dispatch - это фактически перевод рантайм проверки типов в компайл-тайм (и ужесточение оной тем самым) или что-то я не то понял?

а просто диспатч это что?)

помню у нас в универе препод по 1С говорил что если кто то скажет адин Цэ тому пиздец))

мне кажется или хоть как говорить - пиздец

а просто диспатч это что?)

хз ваще :D в примере с фигурами и принтерами - у них там двойная зависимость вышла

для которой они повысили связанность

осталось только понять, почему они плюсы называют CeePlusPlus :D но это так, оффтопик

а че такого

норм же

еще сипипи наызывают

для которой они повысили связанность

или уменьшили)

повысить/понизить связанность => увеличить/уменьшить вероятность изменений зависимых модулей

повысить/понизить связанность => увеличить/уменьшить вероятность изменений зависимых модулей

окей является ли Shape зависимым от Printer? а наоборот?

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

Да он может, но я конечно же имел ввиду, когда он этого не делает, а просто dto

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

Эх жалко в проде я такого никогда не видил

в языках типа java/c# еще пропадает возможность делать полиморфизм, ведь там нет такого ad-hoc как в хаскелях например

а без полиморфизма это ж процедурщина с громоздким синтаксисом

ERROR: S client not available

https://youtu.be/US8QG9I1XW0

Кстати, на тему "полефрексировать о необходимости ООП/ФП в проде": - https://youtu.be/XBfi3Q74BnE - https://youtu.be/b-Eq4YV4uwc

окей является ли Shape зависимым от Printer? а наоборот?

одно будет знать про другое, скорее всего shape при printer Shape { print(printer) { return printer.write(this.firstField, this.secondField, this.thirdField.toString()) } }

одно будет знать про другое, скорее всего shape при printer Shape { print(printer) { return printer.write(this.firstField, this.secondField, this.thirdField.toString()) } }

http://wiki.c2.com/?DoubleDispatchExample

а Printer знает про Shape Printer { printCircle(Circle circle) }

добрый вечер. Кто нибудь разделял в yii2 ar и бизнес логику, какие варианты/рекомендации есть? наследоваться от AR модели как то так себе вроде есть вариант выделить в отдельный namespace "app/modules/services" бизнес логику(без наследования) и из неё дергать ar модель .

добрый вечер. Кто нибудь разделял в yii2 ar и бизнес логику, какие варианты/рекомендации есть? наследоваться от AR модели как то так себе вроде есть вариант выделить в отдельный namespace "app/modules/services" бизнес логику(без наследования) и из неё дергать ar модель .

Привет, не только к Ы2 относится но и к любому AR, логику лучше хранить в сервисах, проще поддерживать.

вот только такая анемичная модель потом будет аукаться.

вот только такая анемичная модель потом будет аукаться.

Чем?

но это уже хоть какойто шаг в сторону выделения слоев :)

Чем?

я тебе целый день рассказывал уже :)

я тебе целый день рассказывал уже :)

Ты про тесты например? У меня до сих пор руки не доходят по МК репку с практикой накидать :(

ну кроме тестов я еще 2-3 вещи могу назвать. но чот я подумал. и все они не прям 100%-ная причина.

ну и во всяких yii и ларавель активрекордах не получится чистую логику выделить. везде будут всякие save() которые портят все

ну и во всяких yii и ларавель активрекордах не получится чистую логику выделить. везде будут всякие save() которые портят все

Ну хотя-бы слои на минималках это уже что-то? А то напихают в AR логики, видишь это и глаз дёргается.

ну хотя бы всякие мелкие методы/отправки почты/100500 запросов для списков из ar вытащить

оо... тут все запущено :)

Ну хотя-бы слои на минималках это уже что-то? А то напихают в AR логики, видишь это и глаз дёргается.

вообще-то суть AR и заключается в том что бы в модель данных пихать бизнес логику

там ассампшен оч простой - AR применим там где логики не очень много. Если у тебя логики больше - можешь заюзать что-то типа Row Data Gateway, то есть у тебя твоя AR либа будет предоставлять тебе модель данных, а сверху обертка (не сервис-менеджер а доменная модель) которая внутри работает со стэйтом

тогда это все более-менее можно тестить и в целом довольно удобно. Если не сервисы-менеджеры.

но если логика нетривиальная - возможно стоит подумать в сторону дата мэпперов. Если логика больше завязана на данные нежели на отношения между данными - можно table gateway и мутить все через SQL

вообще-то суть AR и заключается в том что бы в модель данных пихать бизнес логику

AR это же не Augmented Reality ?

ну и во всяких yii и ларавель активрекордах не получится чистую логику выделить. везде будут всякие save() которые портят все

можно просто сложно

ну и зависит от сложности самой логики. В целом подозреваю что при определенной снаорвке можно где-то 70% задач не через жопу сделать даже на yii. просто вопрос нахер оно надо

AR это же не Augmented Reality ?

Active Record

Active Record

да знает он что это такое

??

ну и зависит от сложности самой логики. В целом подозреваю что при определенной снаорвке можно где-то 70% задач не через жопу сделать даже на yii. просто вопрос нахер оно надо

Вы просто забываете какое его основное назначение. Это rad. И для этого он очень крут. Для небольших приложений. А если так случиться что придется сильно наращивать функционал, тут уже в любом случае без сноровки никуда

Вы просто забываете какое его основное назначение. Это rad. И для этого он очень крут. Для небольших приложений. А если так случиться что придется сильно наращивать функционал, тут уже в любом случае без сноровки никуда

для RAD у меня есть всякие файрбэйзы и rethinkdb с хорайзноами