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

т.е EventListenerы в DO — не очень красиво? а как красивее информировать заинтересованные объекты о изменении какого-то DO? сделать «шину» для сообщений и передавать ссылку на оную в DO и DO будет её дёргать в нужный момент? или контроль изенения DO лежит за его пределами? бизнес-логика смотрит на результат сеттера и вызывает листенеров, список которых тоже в бизнес-логике лежит?

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

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

Почему например hit должен быть абстракцией? Например можно просто включить в него проперти isTarget

либо ссылка на некий агрегатор ивентов

EventStore.recordThat(this, SomeDomainEvent.occuredFor(this.id))

Почему например hit должен быть абстракцией? Например можно просто включить в него проперти isTarget

В типе попадания находятся ещё дополнительные данные, так например в типе TargetHit есть ссылка на мишень

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

И если выносить свойства, мы в целом не уйдём от текущего решения и смешаем специфичные детали

В типе попадания находятся ещё дополнительные данные, так например в типе TargetHit есть ссылка на мишень

Если рассмотреть hit просто как набор значений описывающий как мы попали, то возможно не нужно делить его. Мы просто можем узнать isHitTarget и тогда отдать в обработчик который пошлет на сервер нужные свойства например туже мишень, точку в пространстве . Иначе он отдает общие свойства для визуализации.

Если рассмотреть hit просто как набор значений описывающий как мы попали, то возможно не нужно делить его. Мы просто можем узнать isHitTarget и тогда отдать в обработчик который пошлет на сервер нужные свойства например туже мишень, точку в пространстве . Иначе он отдает общие свойства для визуализации.

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

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

Мысль моя вообщем такая: _shootBroadcaster возвращает абстрактный hit. Но получается что потом это принуждает нас проверять тип hit. Имхо это значит что неправильно что возвращается абстракция, которая в результате не используется. hit может остаться как класс который содержит общее для разных hit-ов. Возможно это должно выглядеть так: _shootBroadcaster.Shoot(shoot); if(_shootBroadcaster.isHitTarget()){ OnHitTarget?.Invoke( _shootBroadcaster.getHitTarget() ); }else{ OnHitEnviroment?.Invoke( _shootBroadcaster.getHitEnviroment() ); }

Если коротко: Зачем возвращается абстракция которую потом все равно обязательно нужно приводить к реализации?

Давайте рассмотрим ситуацию под другим углом. Например у нас есть некий визуализатор анкеты, и есть несколько типов вопросов. Например: выпадающий список и свободный текст. Есть абстракция IQuestion с методом GetAnswer. Как будем делать рисование различных вопросов? Мне кажется наличие в абстракции метода Draw каким-то неправильным

Даже если у нас появится ещё одна абстракция IDrawer с которой визуализатор работает. Всё равно должна быть точка ассоциации одной реализации с другой

что такое MVC модель?

Ну и что это?)

википедия это модель MVC?

ну то есть ты не знаешь

не верю что кто то реально понимает mvc потому что иначе им бы не пользовались

быстро вкинул и ушел

Давайте рассмотрим ситуацию под другим углом. Например у нас есть некий визуализатор анкеты, и есть несколько типов вопросов. Например: выпадающий список и свободный текст. Есть абстракция IQuestion с методом GetAnswer. Как будем делать рисование различных вопросов? Мне кажется наличие в абстракции метода Draw каким-то неправильным

если там будет дабл диспатч то почему нет

Почему бы QuestionType не выражать как раз-таки типом реализации абстракции?

не верю что кто то реально понимает mvc потому что иначе им бы не пользовались

какой из MVC надо понимать?)

их много разных

их много разных

я это и имел в виду

все похоже на mvc. все что вокруг UI

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

Даже если у нас появится ещё одна абстракция IDrawer с которой визуализатор работает. Всё равно должна быть точка ассоциации одной реализации с другой

вообще есть вроде как классическая задача про принтеры различных фигур. Это вроде как как раз про это

но почему-то называются одними и теми же 3-мя буквами... интересно почему бы это?

да и что блядь такое это серверная MVC? высер который родил DDH со своими рельсами? или ты про Model2 в JSP?

вообще есть вроде как классическая задача про принтеры различных фигур. Это вроде как как раз про это

Надо глянуть. Помню только с методом Draw в каждом и пример паттерна Visitor

Надо глянуть. Помню только с методом Draw в каждом и пример паттерна Visitor

ну вот я обычно подобное через визитор разруливаю - так проще и гибче (ну и у меня нет перегрузки методов и дженериков в моем похапе...)

https://heim.ifi.uio.no/~trygver/2003/javazone-jaoo/MVC_pattern.pdf

можешь вот почитать шутки ради... поплакать

что бы еще больше поплакать - сравни с какой-нибудь статьей 2010-ого года написанной школьником о том что такое mvc

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

днем я пишу на тайпскрипте а по ночам я пишу на похапе

я сам выбрал свой путь

котлин няшка

скала - я все ленюсь потыкать..

нет. че там бояться?

Почему бы не хаскель

Почему бы не хаскель

я помню наблюдал как у тебя типы не сходились... боюсь такого)

Не

> Text.pack "" == []

вообще есть вроде как классическая задача про принтеры различных фигур. Это вроде как как раз про это

Неэффективный способ, кстати, моделировать статичные фигуры уже давно смысла нет. По минимуму — описать работу турникета

Не

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

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

Пыха - другой язык?))

Хз, я к счастью на нём не писал))

не верю что кто то реально понимает mvc потому что иначе им бы не пользовались

MVC is a delivery mechanism, not an application architecture.

Для меня это всё определение мвс))

MVC is a delivery mechanism, not an application architecture.

я дал ссылку на первоисточник (правда за 2003-ий год так что там еще и рассуждения на что было 25 лет с момента задумки)

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

добавили оверлоадинг значит работает совершенно иначе

Это не оверлоадинг, это совершенно другой принцип

Там правил на пару листов, называть это сравнением довольно странно

Почему бы не хаскель

А в хачкеле строки это же вроде просто лист чаров т.е пустая строка это пустой лист, в жс же строки и массивы это 2 разные вещи т.е да makes sense :))

Но насчёт хачкеля могу ошибаться

https://wiki.haskell.org/Type_of_empty_list

Все широко используемые языки имеют кучу застарелых несмешных преколов в спеке, разница лишь в том, делается ли что-то. комитетом для создания альтернативного решения и что конкретно

Все широко используемые языки имеют кучу застарелых несмешных преколов в спеке, разница лишь в том, делается ли что-то. комитетом для создания альтернативного решения и что конкретно

И есть ли вообще спека...(

Окей, думаю "традиция" тут более подходящий термин ?

Все широко используемые языки имеют кучу застарелых несмешных преколов в спеке, разница лишь в том, делается ли что-то. комитетом для создания альтернативного решения и что конкретно

синтакс лямбд в питоне это застарелый несмешной прекол?)

синтакс лямбд в питоне это застарелый несмешной прекол?)

Разве не достаточно самого факта его существования?

Там просто комитетом с ним делали что-то, но Гвидо это не понравилось и поэтому ниче не сделали

Какой?) дарт?

(древние Си я не беру в расчёт)

Пхп?)

не знаю, поэтому и спрашиваю

у гошечки вроде не слоник