Архитектура приложения Unity3D (StrangeIoC)

Привет. Хочу поделиться своими мыслями о разработке, которые возникли при работе с юнити и в целом при разработке приложений.

Часто встречаю в и-нете вопросы по поводу того, какой выбрать паттерн или как сделать архитектуру гибкой и тп.

Я выработал свой подход, и вот основные моменты:

Использовать стейт машину
Стейт машина(конечный автомат) — это круто, потому что любое приложение можно представить как набор состояний и переходов между ними.

Всю логику можно поделить на стейты, сервисы и библиотеки. Каждый стейт несет свое бремя в жизни приложения. Типичный пример: есть приложение, в нем есть меню, сама игра и окно выигрыша/проигрыша. Все эти экраны можно представить как состояния, поэтому получится 4 состояния в вашем приложении: меню, игра, выигрыш, проигрыш. Осталось только связать их переходами.

«Чистое» представление
Под словом «чистое» имею ввиду никакой бизнес логики к представлении(view). Весь пользовательский интерфейс должен быть абстрагирован в отдельный уровень приложения — уровень представления. Давайте сразу к примеру:

public class MenuScreen : MonoBehaviour
{
    [SerializeField]
    private Button _playBtn;

    public event Action PlayClicked = delegate { };

    void Start()
    {
        _playBtn.onClick.addListener(()=>{
            PlayClicked();
        });
    }
}


Видим, что поля скрыты (модификатор private), поэтому никто извне не сможет что-то с ними сделать. Для того, чтобы можно было установить значения из редактора, пишет атрибут SerializeField.

Следующее, что нужно выделить, это способ проброса событий. Так как представление может взаимодействовать с пользователем(а точнее наоборот:)), то нужно как-то сообщить логике, что пользователь сделал. Для этого используются события. При щелчке на кнопку генерируется событие, а бизнес логика где-нибудь у себя подпишется на данное событие и как-то среагирует. Удобно ведь?

С данный класс можно включить логику, которая относится непосредственно к отображению, например, добавить метод Show(), в котором сам экран будет появляться с использованием затемнения или еще как-то.

Использовать DI + IoC
Кто еще не слышал что такое DI и IoC рекомендую прочесть статью на хабре. Считаю, что использование внедрения зависимостей это must have для любого проекта.

Какие плюсы:
— легко подключить/внедрить любой тип в любом месте. Достаточно лишь добавить свойство/параметр(если внедрение через конструктор), и вы уже можете работать с новой сущностью.

— легко подменить реализацию какого-либо интерфейса. Есть интерфейс ICar, сейчас мы указываем реализацию Mustang, а через какое-то время подменяем на Audio и весь код теперь работает с новым типом. А поменялась только одна строчка.

— управление lifetime объекта. Обычно, все DI-фреймворки берут на себя заботу о том, как поступать с типом при запросе объекта — создать новый(фабрика) или отдать существующий(привет синглтон!). Все настраивается одной строчкой(или почти одной)

Из минусов — нужно выучить что-то новое, если для кого-то это минус:)

Кое что еще в видео



Всем хорошего кодинга!test

0 комментариев

Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.