Этот паттерн озвучил Bruce Eckel (President, MindView, Inc.) как написано у меня в Thinking in Patterns (Технология решения проблем с использованием Java). даже у него сайт есть. www.BruceEckel.com. Правда я там никогда не был.
В случае передачи параметров отдельными параметрами такой проблемы не - бу - дет:
Да и еще к тому же это даст возможность типизировать параметры (типизировать твой Messenger можно только с напрягом):
Ну вообще то конечно мессенджер родился для типизированного языка.
Вот пхп без типизации. Но ведь зачем создавать нетипизированный язык, чтобы потом везде юзать типы?
Да и сама типизация в пхп это проблема. Уточнение типа в пхп5 это бред какой то.
простой пример. увы я сильно не тестил но мне и этого хватает.
function __construct(DataBase $dbInstance, integer $lowLevel, integer $maxLevel, boolean $hidden = true) {
...
}
При вызове этого коснтруктора мне явно приходится транслировать в (int) ибо чуть не уследил и оно mixed.
Взять же тот конфиг-класс с паблик свойствами. Пусть кто то где то установил свойство в 5 (забыв при этом указать (int)) и трындец - при вызове такого конструктора с использованием свойства вышеописанного конфиг класса будет ошибка.
Я в своих скриптах юзаю только проверку классов, а простые типы проверять - все равно вылетает ошибка несовпадения типов.
Взять тот же Зенд фреймворк. Кое где они проверяют на массив. Ибо передать класс реализующий итератор просто невозможно. Пришлось удалить проверку и все работает как часы.
А если везде за типами следить (что невозможно в принципе, хотя бы с теми же паблик свойствами класса или массивом) то пропадают все преимущества пхп как нетипизированного языка.
Конечно в пхп 5 таки можно это чудо совершить с классами. Но мессенджер тоже класс и тоже может отслеживать. Причем не только проверить простой тип а и насильно (невозможно ж забыть )транслировать его в нужный, дабы далее не было проблем.
Плюс еще одна польза от передачи массива. Я офигеваю писать оффигенно длинные строки вызова. Ибо приходит ко мне обьект класса и мне нужно достать каждое свойство и в итоге получается
$object=new Class($config->DataBase, $config->LowLEvel, $config->MaxLevel, $config->Hidden);
Причем бывает несколько таких надо вызывать и не в цикле. Проще один раз подготовить общую часть массива параметров и немного модифицировать перед вызовом. Экономит время на получения значений свойств.
-~{}~ 25.01.07 17:32:
может сложится впечатление что я защищаю использования массива. но это не так. Я всегда использую явные вызовы пока параметров меньше 5.
Всегда стараюсь создавать класс как черный ящик. Просто у меня бизнес-обьекты которые составляют ядро приложения и шансов что они будут повторно использованы в другом приложении практически нет. А если так то почему бы им не дать знать о том, что у конфига мол такой вот интерфейс.
Что, впрочем я и делаю. Класс требует интерфейс и он совпадает с интерфейсом конфига. Однако мне не помешает при нужде поменять интерфейс конфига (правда придется тогда адаптировать его для бизнес -обьекта перед вызовом)
denver
После долгих писаний на си шарп я пришел к выводу, что любой контроллер (любой класс кто реагирует на действия юзера) должен быть посредником - то есть ничего толком не делать, но знать кто знает и перенаправлять вызов ему. Так же пришел к выводу, что только он должен знать что такое конфиг, как достать его и как передать вызываемому модулю нужные данные. Но модуль не должен знать о конфиге ничего кроме заявленного интерфейса.
Если у кого то другие наработки, прошу сообщить. Ибо вечно учусь.
Так вот была типичная задача. Контроллер получив нажатие кнопки просто доставал конфиг и инициализировал какой то модуль. Этот модуль знал что нужно создать поток (ну не контроллеру же это знать) и создавал его и опять же надо туда передать все параметры. То есть уже 2ная передача. Поток может создать че то свое мудренное (например форму) и туда передать. То есть конфиг идет по уровням. И когда я не оборачивал его в контейнер и приходилось добавлять параметр я лазил по всем этим уровням и добавлял нужный параметр.
Ведь только одному классу положено знать обо всех - посреднику. Остальные пусть знают только о себе.
то есть выполнятся:
Закон Деметера (Demeter): \"Не говорите со странниками\". Объект должен ссылаться только на себя, свои атрибуты и аргументы своих методов.
ager там юзается фабрика. И юзается точно такой же подход. Ибо количество параметров характеризующих класс огромно. А он как и положено, ничего не знает о том где его используют.