Огромное спасибо тебе за такие видео. Скоро у тебя будет дофига подписчиков ты только потерпи немного, и не в коем случае не бросай канал, как многие "unity ютубери" делают. У тебя просто отлично получается объяснить )
Мне очень не понравилась работа со словарём. Делать ContainsKey, а потом ещё не через Add добавлять, а через квадратные скобки, то есть делая ещё кучу икволс и гет хеш код... А ещё делать контеинс кей, а потом ремув... Ну блин: для эдда есть TryAdd: если фолс, то кинешь исключение. Для взятия из словаря есть TryGetValue. Для удаления: Remove и так уже возвращает бул, если не нашёл. А так получается кучу лишних действия над словарями). В случаи с сервис локатором это не страшно, ведь можно закешировать ссылки, но если это будет в каком-нибудь сложном алгоритме и в апдейте... Люди же будут думать, что таких методов нету и будут вот так проверить сначала на наличие ключа, а только потом брать значение и будет алгоритм раза в 1,5-1,8 медленнее со стороны взятия элементов из словаря.
Ролик замечательный, но не прочь его покритиковать. Вот я обычный разработчик, зашедший на это видео. Хочу же узнать на какие службы поставить мне сервис локатор. Что же я хочу услышать с начала видео? Что это за паттерн, какие он задачи решает , какие проблемы ему сопутствуют? А слышу объяснение в два слова и смотрю реализацию паттерна, который решает неизвестные задачи и тд. В итоге , только к концу ролика я могу составить мнение о надобности паттерна....
Спасибо за видео! Когда реализовывал Service Locator, то еще дополнительно делал интерфейс IRequireService public interface IRequireService where TService : class { } И метод расширения public static TService InitializeService(this IRequireService obj) where TService : class { IServiceLocator serviceLocator = Singleton.Instance; if (serviceLocator == null) { return default; } return serviceLocator.GetService(); } И после регистрации необходимого сервиса в локаторе служб public class ServiceLocator : ServiceLocatorBase { protected override void OnInit() { RegisterService(new Service()); } protected override void OnAfterInit() { }
} Можно было получать необходимые зависимости следующим образом public class Test : MonoBehaviour, IRequireService { private IService service; void Start() { service = this.InitializeService(); service.Print(); } } Что, как по мне, делает использование локатора служб немного удобнее и позволяет сразу увидеть какие зависимости требует класс
Рубрика "научи плохому"?) Пробовал как-то статический сервис локатор, со статическим же вложенным классом, избавляет от словарей и проверок, но в конечном итоге понял, что не зря он считается анти-паттерном, когда графы посыпались, перешел на авторезолвер и прям счастлив
Я чистой статикой стараюсь не пользоваться, но видел пару типов архитектур, где статические сервис локаторы отрабатывали очень хорошо. Справлялись со своей задачей, поддерживали версионность и контекст. Думаю, то, является ли паттерн удобным или неудобным - вопрос архитектуры приложения в целом. В любом случае, я показываю инструмент, пользоваться им не обязательно :)
![Warhammer 40k: Space Marine 2 | เพื่อจักรพรรดิ ! [ตอนเดียวจบ]](http://i.ytimg.com/vi/4M0ckYMA4-U/mqdefault.jpg)
Не могу не поблагодарить вас за столь клевые обучающие видео! Спасибо! и всего вам наилучшего!
Спасибо!)
Огромное спасибо тебе за такие видео. Скоро у тебя будет дофига подписчиков ты только потерпи немного, и не в коем случае не бросай канал, как многие "unity ютубери" делают. У тебя просто отлично получается объяснить )
Мне очень не понравилась работа со словарём. Делать ContainsKey, а потом ещё не через Add добавлять, а через квадратные скобки, то есть делая ещё кучу икволс и гет хеш код... А ещё делать контеинс кей, а потом ремув... Ну блин: для эдда есть TryAdd: если фолс, то кинешь исключение. Для взятия из словаря есть TryGetValue. Для удаления: Remove и так уже возвращает бул, если не нашёл. А так получается кучу лишних действия над словарями). В случаи с сервис локатором это не страшно, ведь можно закешировать ссылки, но если это будет в каком-нибудь сложном алгоритме и в апдейте... Люди же будут думать, что таких методов нету и будут вот так проверить сначала на наличие ключа, а только потом брать значение и будет алгоритм раза в 1,5-1,8 медленнее со стороны взятия элементов из словаря.
Спасибо! Новичку самое то 👍🔥
Отличное видео, спасибо!
Спасибо за урок!
Жду новые видео по архитектуре
Ролик замечательный, но не прочь его покритиковать. Вот я обычный разработчик, зашедший на это видео. Хочу же узнать на какие службы поставить мне сервис локатор. Что же я хочу услышать с начала видео? Что это за паттерн, какие он задачи решает , какие проблемы ему сопутствуют? А слышу объяснение в два слова и смотрю реализацию паттерна, который решает неизвестные задачи и тд. В итоге , только к концу ролика я могу составить мнение о надобности паттерна....
Хорошее замечание, учту, спасибо)
Ролик не отвечает на вопрос "что такое паттерн сервис-локатор?". Он отвечает на вопрос, как его реализовать и использовать в условиях юнити
Спасибо за видео!
Когда реализовывал Service Locator, то еще дополнительно делал интерфейс IRequireService
public interface IRequireService where TService : class { }
И метод расширения
public static TService InitializeService(this IRequireService obj) where TService : class
{
IServiceLocator serviceLocator = Singleton.Instance;
if (serviceLocator == null)
{
return default;
}
return serviceLocator.GetService();
}
И после регистрации необходимого сервиса в локаторе служб
public class ServiceLocator : ServiceLocatorBase
{
protected override void OnInit()
{
RegisterService(new Service());
}
protected override void OnAfterInit() { }
}
Можно было получать необходимые зависимости следующим образом
public class Test : MonoBehaviour, IRequireService
{
private IService service;
void Start()
{
service = this.InitializeService();
service.Print();
}
}
Что, как по мне, делает использование локатора служб немного удобнее и позволяет сразу увидеть какие зависимости требует класс
Такой апгрейд неплох, если юзаешь синглтоны. Если архитектура позволяет, то, почему бы и нет)
Рубрика "научи плохому"?) Пробовал как-то статический сервис локатор, со статическим же вложенным классом, избавляет от словарей и проверок, но в конечном итоге понял, что не зря он считается анти-паттерном, когда графы посыпались, перешел на авторезолвер и прям счастлив
Я чистой статикой стараюсь не пользоваться, но видел пару типов архитектур, где статические сервис локаторы отрабатывали очень хорошо. Справлялись со своей задачей, поддерживали версионность и контекст. Думаю, то, является ли паттерн удобным или неудобным - вопрос архитектуры приложения в целом. В любом случае, я показываю инструмент, пользоваться им не обязательно :)
Сделай пожалуйста видео про инвентарь в виде списка.
Зачем он нужен-то. Неплохо бы объяснить вначале ролика)
Как часто используется Service locator? Заменяет ли его Zenject?
Заменяется полностью, это все DI
Почему все говорят, что Локатор Служб - это антипаттерн?
Спасибо, как загрузить код с удалённого сервера
Почему все говорят патЕрн, если пАтерн?
потому что языковая ассимиляция. Почему в америке ставят ударение "Иван", а не "ивАн"?
Кто то будет переписывать свой код на подобный
th-cam.com/video/sglV2kkaIls/w-d-xo.html мы точно возвращаем newServis? А не _itemsMap[type]
Так это одно и тоже, там одна и та же ссылка)
@@gamedevlavka с ссылочными типами всегда почему то лень разбираться) предпочитаю фактическое использование)
@@aarontower с опытом это будет на автомате)