Если есть сервисы которые уже предоставляют для внутрених нужд схожую частную функциональность, то можно использовать эти сервисы для проброса в некоторых слоях.
Можно юзать в одностороннем порядке существующие сервисы, например, для уточнения данных.
Можно написать полностью независимую ветку.
Можно, например, снабжать объекты скрытыми частными интерфейсами и реализовывать внутри объекта (через композицию), но доступ все равно делать через вип сервис.
Главная задача не ломать\захламлять существующие интерфейсы и возможность удаления функциональности без изменений существующих объектов.
По поводу дублирования кода, то у нас он не дублировался. Сервисы были тривиальными и написать даже целую цепочку сервисов было нормально.
По той же причине по которой не используют в других универсальных библиотеках. Нужен всего лишь умный указатель и тащить за собой целый буст и заставлять пользователей его собирать это не вариант. С появлением его в стл упростит задачу, но это произойдет когда большинство компиляторов его предоставят.
Ну так помогите мне придумать пример и сделаем статью лучше!
У меня есть два примера из геймдева:
Первый, это когда из гейм логики объекта вдруг дизайнерам понадобилось изменить цвет материала. Костыль для этого случая был — портить базовый класс объекта знанием о материале. Вот этот паттерн пригодился.
А правильное решение было использовать мощь анимационного графа.
Второй случай это когда опять же из логики необходимо достучатся до протокола и его технических деталей. Тут вообще не было решения и позже потребовалось перепроектирование.
Ядро линукс, драйверы, даже некоторые части игр (например рендер) — это системное программирование, оно отличается от прикладного. Для прикладного программирования придуманы кучи патернов, чтобы огромная армия программистов не отстреливала себе ноги. В системном свои правила, и основное — выжать максимум. Выжимается максимум явно нарушая правила прикладного программирования. Вот для обычных программистов то что в этой статье это ненормальное программирование. Для системого программирования это нормально!
Собственно это я и хотел выразить своим предыдущим посланием.
Я как раз и разгадывая в журналах наткнулся на кросворды в которых два решения. Очень удивился, но быстро понял что там обычная прога для генерации сканвордов, без всяких проверок. Ибо это конвеер.
На все вопросы «почему?» один ответ — это стратегическое партнерство, где цена устройства и другие факторы не являются определяющими.
Может они друг другу лицензируют чтото или у них есть общие рынки или видения будущего рынка. Ничего личного, просто бизнес. (с)
Код можно спрятать в спойлеры. а насчет минусов все просто, тут всегда минусуют, нужно не обращать внимание и дальше писать интересные статьи. Если хоть один плюсанул, значит статья нашла своего читателя.
Статья предназначенна для молодых разработчков. Все описано примитивно но понятно. У нас использовался xml, никаких сценариев не создавалось, создавать второй язык программирования плохая затея. Вместо этого, система проектировалась так, что все моменты можно было указать декларативно, соотвествено данные не были похожи на сценарии. При добавлении сложного функционала, он приобретал вид экшена или валидатора и добавлялся в фабрику, после чего его можно было использовать в декларативном описании чего либо.
Тоже пытаюсь юнити приобщить к светлому, но классически DI контейнер чужероден. В юньке все связи делаются драдропом, объекты могут менять свое положение дизами, и каждый раз править пути это ужас. Стандартное решение в юнити есть, вместо интерфейсов юзать абстрактные классы, тогда разрешать зависимости можно дропом. Но тут другая проблема, абстрактный класс может быть только один в цепочке наследования, поэтому если сервис реализует несколько ролей то, такой вид инекции не сработает.
Если есть сервисы которые уже предоставляют для внутрених нужд схожую частную функциональность, то можно использовать эти сервисы для проброса в некоторых слоях.
Можно юзать в одностороннем порядке существующие сервисы, например, для уточнения данных.
Можно написать полностью независимую ветку.
Можно, например, снабжать объекты скрытыми частными интерфейсами и реализовывать внутри объекта (через композицию), но доступ все равно делать через вип сервис.
Главная задача не ломать\захламлять существующие интерфейсы и возможность удаления функциональности без изменений существующих объектов.
По поводу дублирования кода, то у нас он не дублировался. Сервисы были тривиальными и написать даже целую цепочку сервисов было нормально.
У меня есть два примера из геймдева:
Первый, это когда из гейм логики объекта вдруг дизайнерам понадобилось изменить цвет материала. Костыль для этого случая был — портить базовый класс объекта знанием о материале. Вот этот паттерн пригодился.
А правильное решение было использовать мощь анимационного графа.
Второй случай это когда опять же из логики необходимо достучатся до протокола и его технических деталей. Тут вообще не было решения и позже потребовалось перепроектирование.
Собственно это я и хотел выразить своим предыдущим посланием.
Может они друг другу лицензируют чтото или у них есть общие рынки или видения будущего рынка. Ничего личного, просто бизнес. (с)