Думаю что единственной перспективной технологией Microsoft остаётся только ASP.NET Core. Десктоп разработка для Windows никому не интересна. WPF, UWP и уж тем более WindForma — может быть и поддерживаются но они мертвы в виду отсутствия спроса. Xamarin скорее всего тоже уступит место PWA и Flutter. Стоит ли разработчикам переходить на технологический стек компании которая из года в год теряет свои позиции?
Надеюсь это просто опечатка — нижележащие слои должны быть зависимы на более высокоуровневых слоях. Смысл подобного разделения на слои не только в повторном использовании, но ещё и в локализации влияния изменений (и тестируемости, как вы и сказали). Изменения в низкоуровневый код не должны приводить к изменениям в высокоуровневом коде — бизнес логике, сущностях и юзкейсах. Горизонтальное разделение архитектуры — это так же и способ организации процесса командной разработки. Повторно использовать, как правило, приходится только высокоуровневый код, именно для его изоляции и существует слоистая архитектура. Игнорирование этого принципа приводит к монолитному коду и всем вытекающим последствиям. Я не могу похвастаться таким большим опытом как у вас, но за свою скромную карьеру мне приходилось не раз повторно использовать существующую бизнес логику.
Без возможности приоритизации и фильтрации событий на этом велосипеде можно очень быстро приехать в Race Condition Hell. Советую обратить внимание на библиотеку UniRx, вполне подходит под описанные вами задачи.
Несколько замечаний автору:
1) Роберт Мартин заостряет внимание читателя на различии между software design и software architecture. SOLID — имеет большее отношение к дизайну систем, а не архитектуре как заявлено в заголовке. Непонимание этого — очень большое упущение.
2) Чтение подобной литературы не в оригинале, не на английском так же ведет к не верной трактовке написанного.
Edge действительно становится очень серьезным браузером и обрастает новым функционалом, но работа с закладками все равно не удобная. Если я открыл одну папку со вкладками, то чтобы открыть соседнюю нужно сделать 3 щелчка мышью. В хроме для этого достаточно посто навести курсор. Дополнительное неудобство — отображение скролл баров когда название вкладки не помещается в отведённое ему окно.
А почему не реализовать каждый «статус» как компонент и не делать например так:
_character.AddComponent<Curse>()
Тогда и не нужны корутины — каждый «статус» в своём Start() начинает отсчёт времени, добавляет иконку если ее еще нет, в Update(), изменяет поведение персонажа в зависимости от своей логики и времени действия, а в OnDestroy() заканчивает своё действие.
Исходя из своего опыта могу сказать что вместо связки sigh+cert лучше использовать match. В добавок к функциям sigh и cert, match позволяет содержать в порядке certificates и provisioning profiles дев центре
Как ни старался, ничего не понял. Ни какую задачу пытается решить автор, ни то, зачем нужна вся история с осями и четвертями. Vector3.RotateTowards() не подойдёт для этого?
К недостаткам описанного способа можно так же отнести и сложность отладки. Как правило во время дебага обработчика события стэк вызовов содержит слишком большое количество элементов. А если любите корутины то понять кто же выбросил эвент часто бывает невозможным.
«Хакерская» программа с UI где пользователь должен отметить галочками типы файлов которые он хочет отравить «хакерам», при этом любезно указать логин и пароль для «хакерского» FTP сервера на который эти файлы будут отправленны… Я даже не знаю как на это реагировать…
Пройдет еще немного времени и «хакеры» напишут статью о том как редактировать PATH в Windows 10 для того чтобы пользователь мог запускать «хакерские» программы (наподобие описанной в статье) из командной строки не указывая полный путь к «вредоносному» *.exe
1. Все верно.
2. UI System и, в частности, ExecuteEvents.Execute устроен так, что не обрабатывает неактивные объекты (которые отсутствуют в иерархии сцены, свойство enabled=false и те для которых был вызван OnDisable). Недостаток приведенной реализации в том что при вызове BroadcastExecuteEvents.Execute в цикле foreach ExecuteEvents.Execute будет вызван даже для неактивных объектов, но сам ExecuteEvents.Execute такие объекты проигнорирует.
Это можно решить изменив коллекцию с подписками. Регистрировать не GameObjects, а UIBehaviours, ибо в классе UIBehaviour определен метод IsActive() который можно использовать для избежания лишних вызовов.
Это не лучше и не хуже. Это просто немного другой подход, дающий возможность отказаться от использования стандартных .NET-событий, которые могут привести к серьёзным проблемам с утечкой памяти. А так же, это более консистентно вписывается в EventSystem поставляемую с Unity UI. К дополнительным преимуществам этого способа можно отнести возможность работы с обработчиками событий как с обычными компонентами Unity(например, всегда можно получить ссылку на обработчик через GetComponent<BroadcastInputModule>()).
А может сделают отдельный Provisioning Profile для сторонних магазинов?
1) Роберт Мартин заостряет внимание читателя на различии между software design и software architecture. SOLID — имеет большее отношение к дизайну систем, а не архитектуре как заявлено в заголовке. Непонимание этого — очень большое упущение.
2) Чтение подобной литературы не в оригинале, не на английском так же ведет к не верной трактовке написанного.
Тогда и не нужны корутины — каждый «статус» в своём Start() начинает отсчёт времени, добавляет иконку если ее еще нет, в Update(), изменяет поведение персонажа в зависимости от своей логики и времени действия, а в OnDestroy() заканчивает своё действие.
2) По конвенции имена функций в С# начинаются с большой буквы.
Пройдет еще немного времени и «хакеры» напишут статью о том как редактировать PATH в Windows 10 для того чтобы пользователь мог запускать «хакерские» программы (наподобие описанной в статье) из командной строки не указывая полный путь к «вредоносному» *.exe
2. UI System и, в частности, ExecuteEvents.Execute устроен так, что не обрабатывает неактивные объекты (которые отсутствуют в иерархии сцены, свойство enabled=false и те для которых был вызван OnDisable). Недостаток приведенной реализации в том что при вызове BroadcastExecuteEvents.Execute в цикле foreach ExecuteEvents.Execute будет вызван даже для неактивных объектов, но сам ExecuteEvents.Execute такие объекты проигнорирует.
Это можно решить изменив коллекцию с подписками. Регистрировать не GameObjects, а UIBehaviours, ибо в классе UIBehaviour определен метод IsActive() который можно использовать для избежания лишних вызовов.