Model View Presenter, MVP, Модель Вид Представитель, С#, Unity 

Да и мне тоже)

Спасибо)

Пример не совсем удачный, но задумка была в том что универсального решения в некоторых случаях нет

Мне кажется, вообще mv* паттерны не сильно используют ООП принципы, так что ваше решение мне кажется нормальным

@@sergeykazantsev1655 Я любитель, потому мнение профессионала для меня определённо важно, спасибо!

Так как никто не представлял официально MVA, то судя по интернет-ресурсам есть двойственное его определение. Кто-то на сайтах пишет что MVA это как MVC, только модель не кидает сигналы на вид, а делает это через контроллера. С другой стороны, если посмотреть на схемы на этих же ресурсах, то да, они все рисуют MVP-Passive(ибо с View прилетают ивенты UI). Короче всё смешалось в одну кучу. Но я бы наверное считал что изначально MVA это именно вариант MVC, а не MVP

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

Ну вот, получается можно) Но если допустим те же слоты вылить на терминалы типа однорукого бандита + web игры - всё равно универсальный контроллер будет проблематично написать :)

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

@@sergeykazantsev1655 да кто такой этот ваш Zenject? Его упоминают в комментах почти под каждым видео. Запрашиваю хотя бы вводное видео, с описанием, какие проблемы и насколько хорошо решает.

Собственно к этому в mvvm и пришли) я лишь показал как это предложил автор MVP)

Привет! Все верно. Я как понимаю это пошло от Мартина Фаулера, но если загуглить, все пишут именно supervising controller для модели MVP. Если загуглить MVP - supervising - на нескольких сайтах и статьях будет именно controller Вот блог фаулера martinfowler.com/eaaDev/SupervisingPresenter.html How it Works Supervising Controller decomposes presentation functionality into two parts: a controller (often called presenter) and view. Вот MSDN learn.microsoft.com/en-us/archive/msdn-magazine/2010/september/msdn-magazine-cutting-edge-better-web-forms-with-the-mvp-pattern That’s up to you. In response to these kinds of questions, the MVP pattern has been split in two separate patterns-Supervising Controller and Passive View-whose primary difference is just the amount of code in the view.

Можно. И я вас поздравляю, вы практически изобрели MVVM :) там как раз к этому и пришли

​@@sergeykazantsev1655 мне просто показалось, что нарушается SRP при подходе из видео. По идее же Вью не должен отвечать за логику, не должен вызывать метод из Презентера. Это так или я что-то не так понял?

Вызов метода не является нарушением SRP. Многие классы имеют публичные методы, которые могут вызывать другие классы, и приватные(про protected тоже не стоит забывать) которые работают с логикой внутри. Получается, если ваше предположение продолжать, то публичные методы использовать нельзя. SRP говорит про то что одна логика должна изменяться в одном месте а не в разных

Однозначного ответа на это нет. Я вижу одно теоретическое и одно практическое решение. Теоретическое гласит о том, что на самом деле вид отвечает только за представление, а логика взаимодействия - это уровень презентера, посему надо не использовать монобех и всю юнитишную физику и играться с координатами и сравнивая позицию игрока и интерактивного контроллера чистой математикой, и работать на их уровне. Вроде какая то крупная фирма типа EPAM-а просит на MVP написать тестовое и там как раз они хотят чтобы самолётик летал без использования физики. Такой код будет легко перекинуть на другую платформу, но мне кажется это не столь эффективно и бессмысленное ограничение себя(если конечно нет спец условий) Практическое гласит о том, что я бы во View хранил ссылку на Presenter и я бы сделал так - если сработал условный OnTriggerEnter, я бы во View дёргал метод _presenter.OnInteract(); Авторы MVC и MVP гласят что не надо придерживаться ордотоксальности и подстраивать эти паттерны под себя совершенно нормально Также я лично очень люблю такие кейсы решать через ивенты. Отправить статичный ивент а какой-нибудь менеджер его где-то правильно обработает: и объект уберёт и Player-у прибавит или убавит жизней На последних двух видео я опубликовал новую игру про шаурму, там используется MVVM, видео на эту тему пока нет но можете посмотреть гитхаб, думаю вы пойметё как я организовал связь между Model, View и ViewModel

@@sergeykazantsev1655 спасибо большое за ответ. Я согласен, что не использовать возможности движка - бессмысленно. Поэтому я сделал механику определения цели в своем примере через рейкаст. Но все же не совсем понял что делать дальше. Получается что презентер должен работать с презентером цели. И я застрял не понимая как его грамотно передать. Получается он должен пройти через два view прежде чем он попадет куда надо (метод в презентере игрока) Еще меня смущает то что view и presenter во многих примерах имеют ссылки друг на друга (оба зависят друг от друга). Я не уверен, но это похоже на нарушение принципов solid.

@@sergeykazantsev1655 еще была такая мысль. Поправьте пожалуйста, если я ошибаюсь. Если в MVP инпут обрабатывает view, то можно ли считать что вызов эффекта объекта-цели (например открыть дверь перед игроком) это своего рода инпут в контексте этой двери? Только инициатором теперь является не InputSystem, а объект Player? Получается дверь просто реагирует на какой-то внешний инпут сигнал (кто-то сказал есть открыться). Есть ощущение что это еще сильнее разделяет системы и делает их абсолютной независимыми друг от друга. Возможно меня просто понесло. Надеюсь понятно сформулировал.

Я вообще не уверен что конкретно игрока и препятствия засовывать в MVP хорошая идея. В этом есть какая-то потребность именно в вашей задаче? Обычно MV* для игрока делается если это сетевая игра, но тогда и вся физика считается на сервере, а на клиенте игрок лишь болванка. Или я часто использую MVVM для диалогов и UI-элементов Если всё таки продолжать использовать MVP в вашем случае то да, пролезания в два View не избежать. Я бы сделал ивент в котором бы передавал presenter игрока и объекта, и сделал бы какой-то InteractableController который бы слушал это ивент и потом с этими бы presenter-ами что-то делал. А какие принципы SOLID нарушаются по вашему, если view и presenter имеют ссылки друг на друга?

@@sergeykazantsev1655 да, сейчас перечитал про SOLID и действительно, такого там нет. Но мне казалось что делать прямую двустороннюю связь - плохая идея, и лучше делать так что один знает второго и подписывается на его события, но второй не может напрямую работать с первым. Про MV* архитектуру: я подумал что будет правильно придерживаться одного паттерна во всей системе для консистентности (возможно кроме UI). Все равно же у многих объектов на сцене есть какая-то игровая логика, которую хочется отделить от представления (MonoBehaviour). Поэтому я решил попробовать известные решения и выбрал для MVP на попробовать. Но возможно этим я слишком усложняю код.

У меня к сожалению не было опыта в сочетании StateMachine и MVP. Но вообще то, что вы говорите очень похоже на правду, я бы делал наверное как то так же. State лежал бы в модели, а Presenter-ы постоянно бы переключались. Пока что у меня примеров такой реализации нет, может как нибудь попробую, звучит интересно

А в чём же тогда, по вашему мнению? Я без негатива, мне искренне интересно, вебом никогда не занимался

@@sergeykazantsev1655 , а хрен его знает :)

@@sergeykazantsev1655 , а хрен его знает :) Может быть и с веба пошло, просто с дореактивной поры, когда все сайты, по сути, отдавались через server side rendering(привет php)

Мне кажется незазорным на одну модель сделать несколько presenter-ов и view, каждый из которых приаттачен к своему presenter-у Тут же главное чтобы вам было удобно)

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

ну да, "удобно вам"="удобно вам расширять и поддерживать"

Насколько я могу судить, подразумевается что вид считается пассивным если он не завязан на модель. Отсылать ивенты или вызывать контроллер и говорить ему что что-то изменилось как я понимаю допустимо Материал брал отсюда martinfowler.com/eaaDev/PassiveScreen.html

Цитата самого Фаулера The significant change with Passive View is that the view is made completely passive and is no longer responsible for updating itself from the model.

I guess I will translate it someday...