XsErG
По поводу зависимости от реестра. Это не страшно, потому что изменения в реестре не должны касаться его интерфейса. Он как был get,set, так им и останется, а что он будет с ними делать, хоть сериализовать или в мемкеш ложить не важно для остальных классов.
К тому же Registry в php в почти представленном здесь виде можно назвать паттерном именно для php и заюзав такой вариант вместо кучи неудобных передач вы не выиграете, но и не проиграете уж точно.
А так... ждем "примеси" в 5.4 
OZ_
Registry с "именнованными полями" в похапе получается в одном варианте, когда он не статичен
Да? А кто запретил делать поля в статичном классе?
А значит нужно строить огромную цепочку передач регистра в объекты
Реестры не передают в объекты. В объекты передают поля реестров. Которые могут содержать что угодно.
А еще.. а еще мы юзаем няшку в виде уже не призрачных, а магических __get и __set, ведь вы же хотите иметь не только жестко заданные параметры?
Это только для не статичных объектов, не для реестров.
Почему бы не сделать один суперкласс ( скажем Component) который будет обрабатывать что-то вроде $this->db у всех потомков и выдавать им коннект к бд?
В каком смысле "обрабатывать у потомков"? Быть родителем? Тогда это будет очень жёсткая конструкция.
или $this->template будет выдавать всем потомкам один и тот же шаблонизатор.
А если шаблонизатор нужен будет разный?
Для этого ведь и существует реестр. Цивилизованные люди делают так: создают реестр, создают в нём поле для хранения instance шаблонизатора, а при создании объекта передают ему в конструкторе значение этого поля.
Пример:
MyRegistry::$template = new Template();
$view=new View(MyRegistry::$template);
В таком случае объекты не зависят ни от имени реестра, ни от названия его поля. Они берут только то, что нужно.
И снова имеем то, что имеем ide не будут комплитить обработку __get/__set.
IDE умеют их обрабатывать, вообще-то, благодаря phpdoc @property.
По поводу зависимости от реестра. Это не страшно, потому что изменения в реестре не должны касаться его интерфейса.
Реестр это статический класс. Если он будет использован в объекте, значит будет использовано его имя. Про интерфейс тут уже можно и не думать даже. Если уж целое имя используется.
А так... ждем "примеси" в 5.4
Вот я их очень очень жду. Отличная штука. Только к реестру никаким боком не относится. В реестре методы не хранятся, только переменные.
XsErG
1.Паблик поля в статическом классе - зло. Паблик поля это вообще зло.
2. О да, когда твоему объекту нужно будет десяток значений из твоего реестра я представляю сколько ты будешь писать кода аля new Class(MeRegistry::$var1,MyRegistry::$var2). Поэтому передается регистр. Не надо плясать над независимостью одних классов от других. Чрезмерная разрозненность ничего хорошего не даст, так же как и чрезмерная связанность.
Любое добавление новой сущности в систему через регистр вызовет необходимость редактирования регистра в случае не юзания ацессоров.
3. __гет __сет не для статичных, но если мы хотим юзать как свойства и не иметь паблик переменных, то придется юзать их. Скажем так Registry::r()->template;
4. Когда один родитель, да, конструкция жесткая. Но мы ничего не теряем. Абсолютно, мы получаем практически то, что дадут примеси. Примеси тоже вызовут зависимость. Скажем в основном коннект с бд нужен только моделям, модели в любом случае будут зависимы от одного основного класса модели и так практически везде.
5. Если шаблонизатор нужен будет разный в одном проекте сразу - выкиньте этот проект.
6. IDE умеют обрабатывать, когда ты жестко задаешь свои свойства и с @property, когда они создаются в процессе никакая ide не обработает.
7. Там юзается имя, везде юзаются имена, тебе от них не избавиться.. это похоже на параною 
Если интерфейс изначально продуман и учитывает все нужные вам няшки, то можно насрать на использование имен. Вы просто юзаете этот класс как декоратор и все. А если так страшно, то можете заюзать фабрики, передавать параметры, имена... да много чего можно придумать и все для того, что бы утешить свою боязнь связанности.
З.Ы. Спор бесполезен, у нас разные взгляды на эту тему.
OZ_
О да, когда твоему объекту нужно будет десяток значений из твоего реестра я представляю
Никто не мешает параметры задавать отдельно, не в конструкторе.
Не надо плясать над независимостью одних классов от других.
Вы ошибаетесь. Почитайте принципы [url=http://ru.wikipedia.org/wiki/SOLID_(объектно-ориентированное_программирование)]SOLID[/url] (или тут).
Любое добавление новой сущности в систему через регистр вызовет необходимость редактирования регистра в случае не юзания ацессоров.
эээ.. Чего?
да, конструкция жесткая. Но мы ничего не теряем
Если конструкция жёсткая, значит мы теряем гибкость.
Если шаблонизатор нужен будет разный в одном проекте сразу - выкиньте этот проект.
А если хранилище сессии захочется поменять? А если проект захочется поменять, а каркас оставить? Code reuse - вот для чего всё это делается.
6 и 7 пункт не несут смысловой нагрузки.
Да, у нас определённо разные взгляды. Почитайте вторую ссылку в этом моём сообщении (автор текста - не я), может сможете понять меня и узнать что-то интересное для себя.
XsErG
Я agiledev читаю давно и статью ту тоже читал и не раз в 2007 году еще.
Стоит понимать одну вещь. В большинстве случаев вы юзаете для разработки cms или cmf в котором все или почти все уже есть. Ну не возникнет там ситуации, что вам нужно будет изменить что-то на столько, что использование имени регистра вызовет epic fail. Применять ООП ради ООП глупо.
З.Ы. Что касается сессий, у нас один декоратор Session скажем... Что у него внутри - насрать. у него есть ацессоры, что он делает и через какой движок знает только конфиг всего проекта в котором написано что-то вроде session=memcache. А Session уже сам на основе этого конфига, с помощью фабрики создаст нужный механизм и будет его юзать.
OZ_
и статью ту тоже читал и не раз
Вы сейчас пытаетесь опровергнуть один из важнейших принципов, описанных в этой статье. Так что, читали Вы, видимо, не особо внимательно.
В большинстве случаев вы юзаете для разработки cms или cmf в котором все или почти все уже есть.
Нет, я не пишу для web. А для wap эти фреймворки не подходят. CMS для WAP, которые сейчас гуляют по WAP, это просто стыдоба и позорище.
что использование имени регистра вызовет epic fail
Фреймворки вообще не могут знать, какое имя Вы дадите своему реестру. Соответственно, не используют это имя.
Если захардкодить имя реестра, то все приложения (applications) будут с одинаковым реестром и взаимодействовать никак не смогут.
декоратор Session скажем
если декоратор - совсем другое дело. с таким вариантом я вполне согласен. Я даже его сейчас у себя использую И знаю не только плюсы такого решения, но и минусы.
Мне больше нравится вариант, когда обработчик сессий является динамическим объектом, который реализует интерфейс. Такой instance очень легко заменить и он не создаёт лишнюю связность.