Архитектура приложения Unity3D (StrangeIoC)
Привет. Хочу поделиться своими мыслями о разработке, которые возникли при работе с юнити и в целом при разработке приложений.
Часто встречаю в и-нете вопросы по поводу того, какой выбрать паттерн или как сделать архитектуру гибкой и тп.
Я выработал свой подход, и вот основные моменты:
Всю логику можно поделить на стейты, сервисы и библиотеки. Каждый стейт несет свое бремя в жизни приложения. Типичный пример: есть приложение, в нем есть меню, сама игра и окно выигрыша/проигрыша. Все эти экраны можно представить как состояния, поэтому получится 4 состояния в вашем приложении: меню, игра, выигрыш, проигрыш. Осталось только связать их переходами.
Видим, что поля скрыты (модификатор private), поэтому никто извне не сможет что-то с ними сделать. Для того, чтобы можно было установить значения из редактора, пишет атрибут SerializeField.
Следующее, что нужно выделить, это способ проброса событий. Так как представление может взаимодействовать с пользователем(а точнее наоборот:)), то нужно как-то сообщить логике, что пользователь сделал. Для этого используются события. При щелчке на кнопку генерируется событие, а бизнес логика где-нибудь у себя подпишется на данное событие и как-то среагирует. Удобно ведь?
С данный класс можно включить логику, которая относится непосредственно к отображению, например, добавить метод Show(), в котором сам экран будет появляться с использованием затемнения или еще как-то.
Какие плюсы:
— легко подключить/внедрить любой тип в любом месте. Достаточно лишь добавить свойство/параметр(если внедрение через конструктор), и вы уже можете работать с новой сущностью.
— легко подменить реализацию какого-либо интерфейса. Есть интерфейс ICar, сейчас мы указываем реализацию Mustang, а через какое-то время подменяем на Audio и весь код теперь работает с новым типом. А поменялась только одна строчка.
— управление lifetime объекта. Обычно, все DI-фреймворки берут на себя заботу о том, как поступать с типом при запросе объекта — создать новый(фабрика) или отдать существующий(привет синглтон!). Все настраивается одной строчкой(или почти одной)
Из минусов — нужно выучить что-то новое, если для кого-то это минус:)
Кое что еще в видео
Всем хорошего кодинга!test
Часто встречаю в и-нете вопросы по поводу того, какой выбрать паттерн или как сделать архитектуру гибкой и тп.
Я выработал свой подход, и вот основные моменты:
Использовать стейт машину
Стейт машина(конечный автомат) — это круто, потому что любое приложение можно представить как набор состояний и переходов между ними.Всю логику можно поделить на стейты, сервисы и библиотеки. Каждый стейт несет свое бремя в жизни приложения. Типичный пример: есть приложение, в нем есть меню, сама игра и окно выигрыша/проигрыша. Все эти экраны можно представить как состояния, поэтому получится 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 комментариев