Как стать автором
Обновить

Комментарии 11

я, если честно, решил, что слои это очень просто, чтоб писать на хабре
Примерный вид статьи про архитектуру сервиса поиска гугла:
Вот, собственно я и боялся, что не все знают что такое слои и зачем они нужны а на хабре статьи нет.
Я знаю, что такое слои. Более того сам рисую архитектурные диаграммы. Просто в варианте «четыре квадрата» без деталей или примитивного примера они имеют ограниченную ценность.
Ну так помогите мне придумать пример и сделаем статью лучше!

У меня есть два примера из геймдева:
Первый, это когда из гейм логики объекта вдруг дизайнерам понадобилось изменить цвет материала. Костыль для этого случая был — портить базовый класс объекта знанием о материале. Вот этот паттерн пригодился.
А правильное решение было использовать мощь анимационного графа.

Второй случай это когда опять же из логики необходимо достучатся до протокола и его технических деталей. Тут вообще не было решения и позже потребовалось перепроектирование.
Я думаю, что пример, когда новая «суперважная фича, нужная вчера» ломает архитектуру есть у каждого, кто работал на более-менее крупном проекте. Мне был бы более интересен пример, как вы применили описанный паттерн «VIP-сервис» в реальной жизни. Детали вашего первого примера как раз бы и подошли. Какого типа класс в каком слое, какие функции и т.д.
Добавил пример из реальной практики.
Спасибо. Вопрос по поводу реализации. А не приводит такая ветка к серьезному дублированию кода? Или там возможна односторонняя связь на существующий слой?
Это уже зависит от реализации.

Если есть сервисы которые уже предоставляют для внутрених нужд схожую частную функциональность, то можно использовать эти сервисы для проброса в некоторых слоях.
Можно юзать в одностороннем порядке существующие сервисы, например, для уточнения данных.
Можно написать полностью независимую ветку.
Можно, например, снабжать объекты скрытыми частными интерфейсами и реализовывать внутри объекта (через композицию), но доступ все равно делать через вип сервис.

Главная задача не ломать\захламлять существующие интерфейсы и возможность удаления функциональности без изменений существующих объектов.

По поводу дублирования кода, то у нас он не дублировался. Сервисы были тривиальными и написать даже целую цепочку сервисов было нормально.
У нас его рабочее название было — «Костыль менеджер» что впрочем не удивительно, его задача аккурат это все хоть както менеджить.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории