Какие знаешь архитектурные паттерны на слое UI?

Архитектурные паттерны в UI-слое Unity

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

1. Model-View-Controller (MVC) и его вариации

MVC — классический паттерн, разделяющий логику на три компонента:

• Model — данные и бизнес-логика.
• View — визуальное представление (UI-элементы).
• Controller — посредник, обрабатывающий ввод и обновляющий Model и View.

В Unity часто используют адаптированные версии: MVP (Model-View-Presenter) и MVVM (Model-View-ViewModel).

// Пример структуры MVP в Unity
public class PlayerModel
{
    public int Score { get; private set; }
    public void AddScore(int value) { Score += value; }
}

public class PlayerView : MonoBehaviour
{
    [SerializeField] private Text scoreText;
    public void UpdateScore(int score) { scoreText.text = $"Score: {score}"; }
}

public class PlayerPresenter
{
    private PlayerModel model;
    private PlayerView view;

    public PlayerPresenter(PlayerModel model, PlayerView view)
    {
        this.model = model;
        this.view = view;
        model.OnScoreChanged += UpdateView;
    }

    public void AddScore() 
    {
        model.AddScore(10);
    }

    private void UpdateView()
    {
        view.UpdateScore(model.Score);
    }
}

2. Event-Driven Architecture (EDA)

Основан на событиях (events) и шинах сообщений. UI-компоненты подписываются на события данных (например, OnHealthChanged) и реагируют обновлением, что минимизирует прямые зависимости.

Преимущества:

• Слабая связанность — UI не знает об источниках данных.
• Гибкость — легко добавлять новые слушатели.
• Централизованное управление через Event Bus.

// Пример использования событий
public class GameEvents
{
    public static UnityEvent<int> OnScoreUpdated = new UnityEvent<int>();
}

// В сервисе данных
GameEvents.OnScoreUpdated.Invoke(100);

// В UI-компоненте
public class ScoreDisplay : MonoBehaviour
{
    [SerializeField] private Text scoreText;
    private void OnEnable() => GameEvents.OnScoreUpdated.AddListener(UpdateScore);
    private void OnDisable() => GameEvents.OnScoreUpdated.RemoveListener(UpdateScore);
    private void UpdateScore(int score) => scoreText.text = score.ToString();
}

3. Компонентный подход (нативный для Unity)

Хотя это скорее парадигма, чем паттерн, важно строить UI из переиспользуемых, инкапсулированных компонентов. Каждый UI-элемент (кнопка, панель, HUD) управляет своим состоянием и exposes публичные методы/события для взаимодействия.

4. State Machine для UI

Эффективен для управления сложными UI-состояниями (например, меню, попапы, экраны загрузки). Конечный автомат явно определяет состояния (MainMenuState, GameplayState, PauseState) и переходы между ними.

// Упрощенный пример состояния UI
public interface IUIState
{
    void Enter();
    void Exit();
}

public class UIManager : MonoBehaviour
{
    private IUIState currentState;
    public void ChangeState(IUIState newState)
    {
        currentState?.Exit();
        currentState = newState;
        currentState?.Enter();
    }
}

5. Паттерн Command для UI-действий

Позволяет инкапсулировать действия (нажатие кнопки, drag&drop) в объекты-команды. Это дает возможность реализовать отмену/повтор (undo/redo), логирование и отложенное выполнение.

Критерии выбора паттерна

• Для простых проектов: достаточно компонентного подхода с аккуратным разделением ответственности.
• Для средних/сложных проектов: MVVM или MVP с Event Bus для данных. Это обеспечивает тестируемость бизнес-логики.
• Для UI с множеством экранов: State Machine в сочетании с Event-Driven подходом.
• Для максимальной слабой связанности: Event-Driven Architecture с внедрением зависимостей (DI).

Ключевой принцип, который я применяю — разделение ответственности. UI-скрипты должны заниматься только отображением и обработкой ввода. Вся бизнес-логика, данные и навигация должны быть вынесены в отдельные слои (Presenters, ViewModels, Services, Controllers). Это позволяет:

• Легко тестировать логику без Unity-зависимостей.
• Менять UI с минимальными изменениями в коде.
• Эффективно работать в команде, разделяя зоны ответственности.

На практике часто используется гибридный подход: например, MVVM для данных, Event Bus для коммуникации, State Machine для навигации и Command для сложных действий. Инструменты вроде Unity's UI Toolkit также продвигают архитектуру, близкую к MVVM, через data binding.