¶ Семейство Model-View.
Сюда входят MVC. MVVM, MVP.
Основная идея заключается в том, что в нашей игре выделяется 3 основных системы, каждая из которых ответственна за что-то конкретное: работу с данными, обработку ввода, отображение изменений. Что подразумевается под системой? Объект или набор объектов.
¶ MVC - Model-View-Controller.
¶ Модель
Model - сущность, ответственная за работу с данными - хранение, обработку, изменение. Это игровая логика. Она может состоять из различных подсистем, каждая из которых в свою очередь ответственна за что-то своё.
Например, PlayerModel - модель игрока (управляет координатами, здоровьем, столкновениями и т.д.), EnemyModel, TreeModel (модель дерева - тип, возраст, состояние корней). Данная сущность независима от пользовательского интерфейса и ввода.
При изменении данных идет оповещение представления об изменениях.
¶ Контроллер
Controller - сущность, ответственная за обработку действий пользователя и информации (например, события нажатия клавиши, ввод пользователя) в модель. Принимает решения о том, нужно ли (и как) обновлять представление.
¶ Представление
View - представление. Сущность, ответственная за визуализацию данных и действий пользователя/программы.
Тут не содержится игровой логики или обработки действий пользователя, но имеются инструкции, как отрисовывать различные элементы.
¶ Что нам дает такое разбиение?
Мы четко разграничиваем зоны ответственности между частями нашего приложения, благодаря чему мы изолируем их друг от друга, снижая вероятность критической ошибки при изменениях.
- Что хранит информацию о координатах игроках?
PlayerModel. - Где находится логика изменений координат игрока?
PlayerModel. - Где определяются текстуры игрока, их размер и прочее?
PlayerView. - Где происходит обработка нажатий на клавиатуру?
В Controller, который передаёт информацию PlayerModel, что была нажата клавиша движения вперед.PlayerModelполучает информацию о том, что была нажата клавиша, как-то реагирует на это. АPlayerViewпросто отображает изменения PlayerModel.
Говорится ли тут о том, как именно должен быть реализован PlayerModel? В виде класса или структуры? Или что он должен использовать ООП и наследоваться от чего-то? Нет. Это уже отдельный вопрос того, как именно реализовать PlayerModel.
¶ MVP - Model-View-Presenter
Вариация MVC, в какой-то мере упрощающая работу с этой моделью из-за того, что компоненты связаны друг с другом слабее. А из-за слабой связи становится проще тестировать компоненты по отдельности.
Model и View, в целом, остаются прежними, но теперь они не связаны друг с другом напрямую. Все работу по изменению модели, передачи информации от неё к представлению ложится на плечи Presenter.
¶ MVP - Model-View-Presenter
MVP — это архитектурный паттерн, развивающий идеи MVC и делающий акцент на упрощении взаимодействия между компонентами, что облегчает тестирование и поддержку кода.
В этом паттерне компоненты связаны друг с другом слабее, что обеспечивает более высокую модульность и возможность независимого тестирования каждого компонента.
-
Model (Модель): Так же, как и в MVC, модель в MVP отвечает за бизнес-логику и управление данными приложения. Она не знает ничего о представлении и не взаимодействует с ним напрямую.
-
View (Представление): Отвечает за отображение данных пользователю и реагирование на пользовательский ввод. В отличие от MVC, представление в MVP делегирует обработку всех пользовательских действий презентеру, не содержит логику обработки данных, что делает его более простым и фокусированным на визуализации.
-
Presenter: Является посредником между моделью и представлением. Презентер реагирует на действия пользователя, которые передаются от представления, обрабатывает эти данные (возможно, обновляя модель), и затем обновляет представление. В отличие от контроллера в MVC, презентер содержит значительную часть бизнес-логики, связанной с обновлением представления.
¶ MVVM - Model-View-ViewModel
MVVM (Model-View-ViewModel) — это архитектурный паттерн, предназначенный для упрощения разработки пользовательских интерфейсов, делая акцент на улучшении разделения ответственности между презентационной логикой и бизнес-логикой. Он особенно эффективен в рамках платформ, поддерживающих двустороннее связывание данных, таких как WPF (Windows Presentation Foundation) и UWP (Universal Windows Platform).
¶ Компоненты MVVM
-
Model (Модель): Как и в MVC/MVP, модель в MVVM отвечает за бизнес-логику и управление данными приложения.
-
View (Представление): View отвечает за визуальное представление модели данных и пользовательский интерфейс. Оно реагирует на ввод пользователя и передаёт команды в ViewModel, но не содержит никакой бизнес-логики или прямого управления данными.
-
ViewModel (Представление-модель): ViewModel действует как посредник между Model и View. Она содержит логику представления, которая отвечает за обработку команд от View, реагирование на изменения в Model и обновление состояния View через механизмы связывания данных. ViewModel может также включать в себя валидацию данных, выполнение команд и другие аспекты презентационной логики.
Основная особенность MVVM:
Связывание данных (Data Binding) для синхронизации UI и ViewModel. Это автоматизированное обновление интерфейса пользователя при изменении данных в ViewModel и наоборот, связь между UI и отображаемыми данными в коде. При этом в MVC и MVP у нас тоже есть такая связь, но её мы создаем собственноручно, прописывая вызовы методов/события/колбэки/и т.п.
Ок. Грубо говоря, каждую сущность мы разбиваем на три подсущности, каждая из которых соответствует модели, представлению и контроллеру. Но зачем представление чему-то, что не будет отображаться? Например, система сохранений, т.е. система, которая сохраняет состояние игры. У неё могут быть разные вариации, давайте остановимся на следующих требованиях:
- Загрузка данных: Загружает сохранения с диска
- Выгрузка данных: Преобразует состояние игры в удобный формат (например, JSON) и сохраняет на диск.
- Полная автоматизация: Не будем давать пользователю возможность сохраняться, но расставим чекпоинты по всему миру, которые автоматически будут сохранять игру.
Где здесь представление? Если у пользователя нет возможности сохраняться, то ему даже меню не нужно давать. Модель содержит логику сохранения и получения данных из других моделей. Контроллер? В принципе, он может определять, когда именно нужно сохраняться. Но вот представления будто бы нет.
MVC по большей части применяется к тем вещам, которые должны отображаться на экране. Что делать с остальными? На самом деле, просто считать, что у них нет представления, а есть только контроллер и/или модель. Но как мы будем разрабатывать, к примеру, модель? Если модель - это объект или набор объектов... То можно просто использовать ООП.