Цитата:
|
эта структура так же будет целиком и полностью сросшаяся с конкретным приложением
|
Ничего подобного. Класс будет
получать настройки обычным способом, через сеттеры или параметры конструктора, и легко может быть использован сам по себе в другом проекте или другом контексте, как верно подметил
expl. Если же класс содержит импорт класса-провайдера настроек, чтобы
запросить у него данные, Вы не можете использовать его как есть, без этого другого класса. Это и называется сильной связностью – когда один класс требует для работы создание определенной среды, других жестко определенных вышестоящих классов (читай - подстройки всего приложения под себя). Вместо того, чтобы передать этому блочку текст, стиль, картинку и размеры, Вы импортите в него статический провайдер, хранящий настройки для всего и вся в приложении, и учите его "звонить в штаб". Соответственно ни в каком другом проекте этот класс работать не сможет, пока Вы не соберете для него этот Штаб и не настроите его так, чтобы он (штаб!) умел удовлетворять ваш капризный классик.
При "каскадной" инициализации Вы передаете экземпляру только то, что нужно конкретно ему (естественно, включая то, что нужно для инициализации его детей-составляющих, если они есть). Класс ни к чему не привязан. Он не требует наличия команды поддержки. В этом смысл "абстракции"/самодостаточности и "инкапсуляции". Да, он тоже требует параметров для настройки. Но, в отличие от штабиста, он требует ТОЛЬКО то, что ему нужно, и не требует ИСТОЧНИКА, а только сами данные. Поэтому неважно, в каком проекте он используется, ему надо только размеры, стиль, текст и картинку, но не структуру, отдающую эти данные. Вам не надо городить для него специальных точек доступа ВЫШЕ этого класса, выискивая в его коде, кого и за какие сиськи он будет дергать во время работы, вам надо передать нужные настройки в публичные точки доступа
самого этого класса, и все. Это "универсальность" и "повторное использование". Почитайте уже ООП. Пора.