PHP:
Kernel::getInstance(); // Согласно Singleton
Вот скажите, с какогу перепугу Вы сами послезавтра или кто-то другой с отличной от Вашей логикой, может догадаться что в результате Kernel::getInstance() будет сформирована страница? Где тут это написано? Вместо легко понятного ну хотя бы
PHP:
Kernel::getInstance()->showMeThePage();
Вы будете долго рыться в коде или писать, а затем читать килограмы документации по проекту... Но это так, присказка.
Идем далее. Конструкторы не предназачены для того, что бы служить точкой входа. Конструкторы предназначены для конструкции объекта, то есть его предварительной инициализации. Теперь ответьте на вопрос
Почему
если у меня добавляется новый сторонний классВ, мне придется переписывать аргументы всех методов классов модулей?
Потому что конструкция Ваших объектов не подразумевает никакой модификации состояния объекта после его конструкции. Вы жестко ограничили варианты использования объекта исключительно через конструктор. И, да, если завтра Вам понадобится добавить помимо $db еще какой-то объект, Вы будете долго и нудно переписывать аргументы всех зависимых методов.
Ваши классы должны быть спроектированны таким образом, что бы пользователь класса имел возможность ПОЛНОСТЬ влиять на поведение экземпляра. У Вас все с точностью до наоброт. Вы предусмотрели только один вариант использования класса - результат, который будет получен после отработки конструктора. То есть Вы даже не сможете повторно получить тот же самый результат без повторной конструкции экземпляра.
Если бы у Вас было хотя бы так
PHP:
// Здесь мы просто указываем конкретные объекты
$k = Kernel(new MySpecificDb($config),new MyOtherSpecific());
// и мы можем в любое время сделать все что угодно и с этими
// объектами и с ядром, изменив его поведение путем
// подмены этих объектов
$myDb = $k->getDatabase();
$k->setDatabase(new LogQueries($myDb));
// другой код инициализации
// После всего этого мы заставляем ядро выполнить свою задачу
$k->runPage();
То Вы просто бы добавили новую пару set/get в ядро. При этом старые классы, которые эту фишку не используют, не подвергались бы риску сломаться.
PS. А адаптор используется именно для адаптации одного интерфейса под другой. Я сначала не понял в чем проблема с аргументами.
-~{}~ 13.05.08 14:07:
В догонку
Есть класс Config, его методы (первоначальная загрузка параметров конфигурации из БД, получение значение конфигурационного параметра по ключу) используются в других методах других классов многократно (Kernel, Module).
Может быть единственный экземпляр класса Config используется многократно? Это разные вещи:
1. я создал 50 экземпляров класса Config, методы каждого из которых вызывались по 1 разу - я 50 раз использовал тип Config.
2. я создал 1 экземпляр класса Config, методы которого вызывались 50 раз - я 1 раз использовал тип Config.
Какая разница, сколько раз Вы сложите два числа, если практическая ценность типа число в программе от этого не меняется? Насколько выше ценность типа число в программе, которая использует 500 различных числовых значений, то есть использует тип число 500 раз?
