История изменений

Если ты засунешь это в компонент, то 1) в компонент придется передавать толстый конфиг, из которого нужна только часть 2) компонент должен будет уметь извлекать из толстого конфига свою небольшую часть.

Давай для простоты считать, что в конфиге данные типа JSON, и нет потребности заморачиваться над кастомными типами. Для конфига это вполне разумное упрощение.

В твоем случае «толщина» заключается только в наличии префикса. От этого не должно быть особых проблем.

Что касается «компонент должен уметь извлекать» - нет, не должен. Предоставь с конфигом стандартные методы извлечения листа. Компоненту останется только их дернуть, передав префикс.

Попробуй мысленный эксперимент: сможешь ли ты использовать свой компонент в другой программе, не меняя его? С толстым конфигом - нет.

Это плохой эксперимент. Во-первых это не надо :). Во-вторых там где надо - это уже не компонент, а библиотека, где расклад совсем другой. Если у тебя библиотечный модуль должен сохранять стейты, то скорее всего что-то пошло совсем не так.

С твоим подходом компонент получает данные, которые ему не нужны. Это избыточность. Насчет модульности - см. мысленный эксперимент выше.

Он получает только класс конфига, не зная что внутри, и методы извлечения нужных данных. Тут нет избыточности.

Таким образом юнит-тест тоже знает, какое поддерево кому нужно.

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

Если ты засунешь это в компонент, то 1) в компонент придется передавать толстый конфиг, из которого нужна только часть 2) компонент должен будет уметь извлекать из толстого конфига свою небольшую часть.

Давай для простоты считать, что в конфиге данные типа JSON, и нет потребности заморачиваться над кастомными типами. Это конфига это вполне разумное упрощение.

В твоем случае «толщина» заключается только в наличии префикса. От этого не должно быть особых проблем.

Что касается «компонент должен уметь извлекать» - нет, не должен. Предоставь с конфигом стандартные методы извлечения листа. Компоненту останется только их дернуть, передав префикс.

Попробуй мысленный эксперимент: сможешь ли ты использовать свой компонент в другой программе, не меняя его? С толстым конфигом - нет.

Это плохой эксперимент. Во-первых это не надо :). Во-вторых там где надо - это уже не компонент, а библиотека, где расклад совсем другой. Если у тебя библиотечный модуль должен сохранять стейты, то скорее всего что-то пошло совсем не так.

С твоим подходом компонент получает данные, которые ему не нужны. Это избыточность. Насчет модульности - см. мысленный эксперимент выше.

Он получает только класс конфига, не зная что внутри, и методы извлечения нужных данных. Тут нет избыточности.

Таким образом юнит-тест тоже знает, какое поддерево кому нужно.

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