Хорошая практика для слоя отображения Unity или как делать View

Любой объект на сцене так или иначе должен отображать данные. Рассмотрим пример.

PlayerHPBar:
Частенько, в гайдах, нам предлагают писать PlayerHPManager, который содержит ссылки на картинку, текст, набор анимаций, тоглы и так далее.
Этот же класс берет или подписывается на изменения характеристик персонажа, в общем как-то связывается с цифрами:

PlayerLogic => PlayerHPManager => Сцена

Плюсы:
+ Понятность
+ Низкий порог входа

Минусы:
- Прослойка между сценой и данными начинает отвечать за несколько вещей: какие данные откуда брать, в какой момент, как именно это отображать
- Изменения отображения тянет за собой изменение менеджера
Даже для игрушечного примера, можно увидеть много подводных камней. Как обновлять MaxHP, как обработать крайние случаи, как отобразить, что персонаж умер, в каком формате отобразить текст и т.д. Это все, как будто бы должно обрабатываться отдельно.
Я не буду рассказывать про чистый код, эта тема отдельная (см. SRP, SoC). Я лишь хочу предложить отделить ту саму часть, которая тянет текст, тоглы, слайдеры и т.д. в отдельный класс. Тогда схема будет такой:
PlayerLogic => PlayerHPManager => PlayerHPContainer => Сцена
Плюс ко всему, выделите отдельный общий класс Container<T> который позволит вам подменять разные реализации для одних типов.

Плюсы:
+ Понятность сохраняется
+ Гибкость
+ Расширяемость и полиморфизм. Возможность подменять реализации
+ Меньше перегруженности

Минусы:
- Чуть больше инфраструктурного кода
- Есть особенности с размером кодовой базы на мобильных устройствах с дженериками
- Требует дисциплины
- Сложнее в отладке и "путешествиях" по коду

Многие вещи в коде были упрощены в угоду понятности. Если есть вопросы, задавайте.