bars80080, может просто в конструктор передать? Агрегирование пойдет?

В register ты всегда можешь контролировать, что у тебя там лежит и зачем. К примеру, можешь сделать его read only или вести логи к его объектам или же вовсе изменить способ хранения объектов.
А globals - это просто бесконтрольная помойка переменных.

изначально - не помойка, но может такой стать

вот, интересный момент.

допустим, так:


по сути здесь мы и отделяем имя переменной от того что происходит в классе
такая постановка грозит чем-нибудь? дублированием объекта или иными заморочками?

а с какой это стати объект будет дублирован?

bars80080, иногда пугаешь)
ты пишешь под четверку?
По ссылке передашь и не будет никакого дублирования

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

Получите системные знания по объектно ориентированом проектировании. Системности знаний могут помочь книги, а не ответы на форуме или статьи. 

Из того, что читал я, могу посоветовать:
Т.н. банда четырех - хрестоматийная книга, но тяжела для восприятия. 
Фаулер - Архитектура корпоративных программных приложений. Опять же хрестоматия, но читается намного легче (как и все его книги).
Мэтт Зандстра - PHP. Объекты, шаблоны и методики программирования - написана легко, примеры на php, примеры на web задачах.

фиг знает. я тут заметил одну заморочку в js, что если приравнять один массив m1 к другому m2, то m1 станет ссылкой на m2.
а мне ответили, что так и должно быть (в смысле, это нормально для языка иметь такой механизм)



ряд сайтов лежит на хосте с 4-кой. стало быть поддерживаем



это всё хорошо, но время, время...

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

возьмём эту литературу на заметку

Для меня это было очевидно, но хорошо. Исправил.


Минутку. Вам провести тест мешала именно статическая зависимость.
Вы ее не убрали, вы сменили шило на мыло. Теперь вместо правки кода Server мы будем править код Locator. А чем это лучше?

Избавится от статических зависимостей внутри класса вы можете инъекцией зависимости (Dependency injection), или паттерном строитель(Builder), который будет строить/собирать нужный объект. Вы не сделали ни того, ни другого. В чем был смысл сотрясания воздух в статье?

А финальный пример с toolkit вы там видели? Это же абзац полный. Вы создали жуткий звездный объект помойку. В котором неизвестно, что, где, когда и откуда.

Меня от этого вылечила идея автогенерируемой самоорганизующейся базы на архитектуре EAV. Идея прикольная - спору нет. Вот только удобство поддержки и качество ее работы - удручали.
Постоянный профайлинг (иначе не будет автооптимизации) - убивал производительность.
EAV - переложил всю логику связей и контроля целостности данных на приложение (это надо было реализовать таки, а в БД уже был готовый механизм).
Администрирование базы требовало написания специфических утилит потому что база практически ничего не знала о том, что лежит внутри нее.

Как итог куча лишнего геморроя. За облегчение жизни в виде прозрачного маппинга моделей в базу и отсутствие необходимости думать над ее структурой.

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

Добавлено @ 13:55

Если не поставишь в конструкторе проверку на соответствие интерфейсу - грозит неработоспособностью 

То что ты написал это dependency injection вкупе с delegation

P.S. что меня еще убивает в паттернах, так это то, что для осуществления похожих действий существует не один паттерн :(

Это сообщение отредактировал(а) Simpliest - 25.9.2009, 13:55

так эта...


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


а разве статических зависимостей не стало меньше? 


я этим toolkit'ом не пользовался и мне не очевидно, что это помойка. Я считаю так: ее можно превратить в помойку

Там останавливаются на конкретном решении, - которое им подошло, - Service Locator.
Dependency Injection упомянут вскользь, видимо, для них он оказался слишком сложным.

И в свете

Их осталось столько же.

Был один "звездный" объект мы его заменили другим объектом путем прямого редактирования кода объектов.
Статическая зависимость, которая якобы мешала ТДД осталась.
Надо будет опять поменять - мы будем или редактировать эти объекты или будем увеличивать "звездность" и запутанность Service Locator.

А представьте, если нам нужно будет добавить новый функционал не затронув старого для соседей?
В случае Injection я просто в конкретном месте передам новый объект реализующий нужный интерфейс.
В случае Locator -  мне придется выдумывать пляски с бубном.  Мне нужен объект с интерфейсом IA, а какой конкретно из 2х - хрен его знает. 

Смысла телодвижений 0. Оставались бы уже с Singleton.

в смысле?

Внедрение зависимости. Ну а по делигации -- в гугл )

для нашего сурового и слегка окостеневшего моска там слишком тонко написано. тонко и размазанно

а в трёх фразах можно же?

Конечно можно. Внедрение зависимости, это когды зависимости внедряются, а не содержатся в исходном коде класса ))