Не в качестве рекламы, посоветую посмотреть на Дзен-мани. Я долгое время перебирал способы наиболее простого мониторинга семейного бюджета, перепробовал разные варианты, и самым удобным оказалось именно дзен-мани.
В чем преимущества? Они умеют подключаться к апи банков и синхронизировать расходы и доходы автоматически. Это оказалось настолько удобно, что я раз в день перед сном просто проверяю правильные ли категории были заасайнены на расходы
Тогда получается, что для нового кода и новой схемы данных, оперирующими PersonEx и передающих PersonEx в легаси-код, два Иванова Ивана с разными отчествами — два разных человека, а легаси-код выведет в какой-нибудь отчет или файл обмена запись только об одном человеке.
наверное мы не до конца друг-друга понимаем, при проектировании легаси кода никто не закладывался на возможные вариации, и часть системы старой уже оттестирована и в продакшене, поэтому она и представляет предметную область. Если я начинаю допиливать (PersonEx и т.д.) то я скорее всего задумываюсь о каких-то других/новых частях бизнес модели (ну например расширить понятие Person).
Поэтому думаю, что реализация Equality в самом типе данных имеет очень малую степень применимости — делать сравнение только для объектов с идентичным рантайм-типом, и только для объектов с семантикой «значение» (и сущность Person тут не подходит, кстати).
Во всех остальных случаях нужен кастомный компаратор в зависимости от задачи, и вопрос в том, что, легаси код должен уметь принимать такой компаратор для сравнения.
здесь абсолютно согласен, даже можно переформулировать — при проектировании бизнес-логики, имеет смысл внедрять зависимость от компаратора, так как это поможет и в тестировании и в поддержке в будущем. В моем варианте получлось бы так, что когда внесли новый тип данных и использовали старый компаратор — нашли бы ошибку в нем, и принцип LSP не был бы нарушен
Тогда получается, что для нового кода и новой схемы данных, оперирующими PersonEx и передающих PersonEx в легаси-код, два Иванова Ивана с разными отчествами — два разных человека, а легаси-код выведет в какой-нибудь отчет или файл обмена запись только об одном человеке.
наверное мы не до конца друг-друга понимаем, при проектировании легаси кода никто не закладывался на возможные вариации, и часть системы старой уже оттестирована и в продакшене, поэтому она и представляет предметную область. Если я начинаю допиливать (PersonEx и т.д.) то я скорее всего задумываюсь о каких-то других/новых частях бизнес модели (ну например расширить понятие Person).
Поэтому думаю, что реализация Equality в самом типе данных имеет очень малую степень применимости — делать сравнение только для объектов с идентичным рантайм-типом, и только для объектов с семантикой «значение» (и сущность Person тут не подходит, кстати).
Во всех остальных случаях нужен кастомный компаратор в зависимости от задачи, и вопрос в том, что, легаси код должен уметь принимать такой компаратор для сравнения.
здесь абсолютно согласен, даже можно переформулировать — при проектировании бизнес-логики, имеет смысл внедрять зависимость от компаратора, так как это поможет и в тестировании и в поддержке в будущем. В моем варианте получлось бы так, что когда внесли новый тип данных и использовали старый компаратор — нашли бы ошибку в нем, и принцип LSP не был бы нарушен
И в любом случае, это будет неверно с предметной точки зрения, т.к. сравнивать записи «Иван Иванов» и «Иван Иванович Иванов» не имеет смысла — вы не сможете сказать, равны эти записи или нет.
ну как раз таки смысл в том, что с точки зрения легаси кода «Иван Иванов» и «Иван Иванович Иванов» для меня одно и то же, так как при проекторовании кода я вообще не знал что может быть Иванович или какой-то PersonEx и мне в принципе не важно это в моем легаси коде. Оба объекта типа Person — OK, оба объекта имеют одинаковые значения в поля Name и Surname — OK, значит они равны. Именно это закладывалось при проектировании старого метода.
Тогда вы получаете немасштабируемый код — любое новое наследование от Person или PersonEx потребует копипасты одинаковых проверок во всех типах иерархии, порожденных от Person.
Согласен. А что если просто при несовпадении типов в PersonEx делегировать сравнение в базовый класс? Тогда конечно получается, что объекты будут равны если их типы не совпадают по базовому сравнению. В этом, ВОЗМОЖНО, есть смысл, так как тогда мы LSP не нарушим и будем всегда уверены, что наш протестированный код работает как надо.
т.е. везде при работе с данной записью не используете отчество, то встает вопрос, почему используется PersonEx, а не Person.
ну вот был у меня написан метод, когда еще не предполагалось наличие PersonEx, и я ожидаю что при добавлении наследника мой код продолжит работать как и раньше (опять тот же LSP)
а почему мы должны следовать логике, что в случае если объекты не равны по типу, то они не могут быть равны между собой? Объекты различной природы? Но мы же всегда можем сказать, что PersonEx as Person (филисофский вопрос в том, знаем ли мы что это на самом деле PersonEx когда работаем с Person)
Мне интересно порассуждать: а что если мы моделируем предметную область, и понимаем, что есть где то метод, который принимает Person и внутри вызывает Equals(), например легаси код. Тут мы создаем наследника PersonEx и начинаем теперь экземпляры PersonEx передавать в метод. В легаси коде мы не знаем что у нас может быть PersonEx и что мы теперь добавили сравнение по типу. При дебаге в рантайме мы то конечно увидим, что объекты уже разного типа, но с точки зрения метода мы не сможем отличить PersonEx и Person, если, например у них равны все поля кроме MiddleName. Получается ли нарушение LSP в таком случае?
В довесок к хорошей статье скажу что и события не обязательны — решать обработку сообщений можно и на уровне данных, имею ввиду отдельную джобу, которая выгребает заказы, которым еще не было отправлено в сообщение, помещает из в очередь, а оттуда они уже рассылаются. В таком подходе есть место для маневров масштабируемости и полной разгрузки основного сервиса с которым взаимодействуют пользователи
еще важный момент это понимать какой компонент разрабатывается — если это каркас/фреймверк, то скорее всего понадобятся хорошо продуманные абстракции, в случае же разработки доменной логики или каких-то инфраструктурных вещей — нужно делать максимально понятно и строго
Мое мнение как разработчика, достаточно долго пишущего на WPF, что ViewModel ни что иное как абстракция View (на самом деле из названия понтяно)). Суть вьюмодели в том чтобы в абстрактном виде задавать то, как должна выглядить вьюха. Так например в wpf есть классы, которые абстрактно описывают коллекции (например ListCollectionView, ObservableCollection). Мы и пишем вьюмодель ориентруясь на асбтракцию представления. А то КАК будет отображена это коллекция (ListView или ListBox или TreeView) решается на уровне представления. Это я все к тому что, по хорошему, не место значений размеров окна во вью модели, это исключительно ответсвенность вьюхи, вьюмодель — абстракция
Мне кажется, или это решение очевидное в силу того что это ASP.NET MVC? Вроде же как в конвейере можно переопределить практически любую часть. (Я к тому что такое решение самое «природное»)
Не в качестве рекламы, посоветую посмотреть на Дзен-мани. Я долгое время перебирал способы наиболее простого мониторинга семейного бюджета, перепробовал разные варианты, и самым удобным оказалось именно дзен-мани.
В чем преимущества? Они умеют подключаться к апи банков и синхронизировать расходы и доходы автоматически. Это оказалось настолько удобно, что я раз в день перед сном просто проверяю правильные ли категории были заасайнены на расходы
О чем собственно статья?
"предпочитайте композицию наследованию" :)
наверное мы не до конца друг-друга понимаем, при проектировании легаси кода никто не закладывался на возможные вариации, и часть системы старой уже оттестирована и в продакшене, поэтому она и представляет предметную область. Если я начинаю допиливать (PersonEx и т.д.) то я скорее всего задумываюсь о каких-то других/новых частях бизнес модели (ну например расширить понятие Person).
здесь абсолютно согласен, даже можно переформулировать — при проектировании бизнес-логики, имеет смысл внедрять зависимость от компаратора, так как это поможет и в тестировании и в поддержке в будущем. В моем варианте получлось бы так, что когда внесли новый тип данных и использовали старый компаратор — нашли бы ошибку в нем, и принцип LSP не был бы нарушен
наверное мы не до конца друг-друга понимаем, при проектировании легаси кода никто не закладывался на возможные вариации, и часть системы старой уже оттестирована и в продакшене, поэтому она и представляет предметную область. Если я начинаю допиливать (PersonEx и т.д.) то я скорее всего задумываюсь о каких-то других/новых частях бизнес модели (ну например расширить понятие Person).
здесь абсолютно согласен, даже можно переформулировать — при проектировании бизнес-логики, имеет смысл внедрять зависимость от компаратора, так как это поможет и в тестировании и в поддержке в будущем. В моем варианте получлось бы так, что когда внесли новый тип данных и использовали старый компаратор — нашли бы ошибку в нем, и принцип LSP не был бы нарушен
ну как раз таки смысл в том, что с точки зрения легаси кода «Иван Иванов» и «Иван Иванович Иванов» для меня одно и то же, так как при проекторовании кода я вообще не знал что может быть Иванович или какой-то PersonEx и мне в принципе не важно это в моем легаси коде. Оба объекта типа Person — OK, оба объекта имеют одинаковые значения в поля Name и Surname — OK, значит они равны. Именно это закладывалось при проектировании старого метода.
Согласен. А что если просто при несовпадении типов в PersonEx делегировать сравнение в базовый класс? Тогда конечно получается, что объекты будут равны если их типы не совпадают по базовому сравнению. В этом, ВОЗМОЖНО, есть смысл, так как тогда мы LSP не нарушим и будем всегда уверены, что наш протестированный код работает как надо.
ну вот был у меня написан метод, когда еще не предполагалось наличие PersonEx, и я ожидаю что при добавлении наследника мой код продолжит работать как и раньше (опять тот же LSP)
Мне интересно порассуждать: а что если мы моделируем предметную область, и понимаем, что есть где то метод, который принимает Person и внутри вызывает Equals(), например легаси код. Тут мы создаем наследника PersonEx и начинаем теперь экземпляры PersonEx передавать в метод. В легаси коде мы не знаем что у нас может быть PersonEx и что мы теперь добавили сравнение по типу. При дебаге в рантайме мы то конечно увидим, что объекты уже разного типа, но с точки зрения метода мы не сможем отличить PersonEx и Person, если, например у них равны все поля кроме MiddleName. Получается ли нарушение LSP в таком случае?
Автору спасибо, идея очень хорошая!