Кстати да, поспорить особо не с чем, иерархия рулит.
Но в промежуточных по иерархии классах может появляется код который только передает общие объекты к младшим.
Вот эти младшие ссылались бы на глобальный синглтон, например.

Тут все определяется уверенностью в том что, не потребуется 2-й логгер, например(их обычно глобальными делают, хотя даже логгер мне таки потребовался второй на текущем проекте)

На самом деле я не фанат глобальных вещей.
Потому что в один прекрасный момент младшему объекту потребуется передать параметр в зависимости от того, кому он принадлежит - всё! Глобальные точки доступа можно выкидывать и чесать репу.

Очередная тема, которая приведет к холивару )

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

здесь под связанностью имеется в виду зависимость объекта не от непосредственного класса его содержащего или манипулирующего им, а опосредованная зависимость от классов уровня приложения.
То есть объект получается связанным, сросшимся с конкретным приложением, его конкр. структурой.
Вот это - не комильфо.

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

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

Смотрю, флейм никак не остановится. :)
Давайте уж говорить конкретно - не только про выигрыш, но и про затраты.

В условиях, когда приложение развивается по диздоку, который пересматривается постоянно (конкуренты, желания пользователей, тестирование игровых технологий и пр.), мы не знаем заранее, где и когда нам потребуется что-то настраивать в зависимости от параметров приложения, поэтому, если хотим остаться в рамках корректного ООП (т.е., отдаем всем объектам только то, что им положено знать), мы влетаем в очень большие издержки по модификации кода каждый раз, как только появляется необходимость передать новый параметр сверху в самый низ.

Вариант с объектом-оберткой для всех параметров AppSettings (или как-то так), который мы закладываем на этапе проектирования и передаем всем сверху вниз через конструкторы, позволяет минимизировать затраты по доработке, но нарушает правило, что каждый получает только то, что должен, значит корректным признан быть так же не может.

ЗЫ. По поводу реиспользования кода - мне искренне хотелось бы посмотреть на реиспользование окна банковских операций по переводу валюты соцсети в игровую валюту в приложениях, не связанных с социальными сетями. Но это так, реплика из зала.

mikhailk, goodguy, вы просто не постигли Дао

Я что-то такое подозревал. :D

Аа, так вон оно в чем дело :D

Не, а по большому счету я согласен с Wolsh'ем, и сам использую иногда глобальные переменные только из лени ) В серьеных проектах всегда исползьзую подход описаный Волшем

Мне кажется все зависит от проекта, ведь реализовать любой проект можно по разному, в зависимости от нужд и удобства.
Вот например, недавно делал приложение, показывающее некие списки, данные в которых постоянно меняются с сервера. Ну и более в приложении ничего небыло. Так вот сами списки - есть ни что иное как нарисованная кодом графика, и тут я использую класс глобальный переменных, - зачем? Ну захотелось мне сменить ширину блока, высоту, или просто цвет,( градиентный например ), с одной стороны - можно и в коде поменять, да фигня, а с другой стороны если graphics идет следующим образом типа moveTo, lineTo и т.д. раз 100 ( ну красивую я фигуру рисую - ок ) , то проще изначально поменять внутри этих мувов и лайнов, на глоб константу, и теперь в любой момент я получу нужный мне скин сменив только 2 строчки, не гробя весь код, с другой стороны эти переменные можно и в классах зашивать и там уже тоже менять по 2 строки да и все. Ну а если у нас несколько не взаимосвязанных классов, которые реализуют графику приложения ? В каждый класс лезть , искать и править по 2 строчки, когда проще открыть конфиг файл и в нем все сразу и поправить? Имхо - тема холиварная, из оперы - МВС или не МВС, каждый пишет как ему удобнее, главное чтобы это конкретно не было Быдлокодством, ну а чуть чуть можно :D