Должны ли все передние классы использовать Singleton?

Question

Рассмотрим шаблоны архитектуры приложения Мартина Фаулера, а также шаблон переднего контроллера: http://martinfowler.com/eaacatalog/frontcontroller.html.Видимо, он использует синглтон. Ну, у меня есть пакет классов в приложении PHP, который работает вместе (например, пакет контроллера Zend), и есть один класс, который делает их все полезными для этого, и поскольку он напоминает большую часть концепций переднего контроллера, я назвал его Packagename_front. Но это не должно быть классом Singleton (в отличие от переднего контроллера), так что я до сих пор позвольте ему иметь имя фронта? Если нет, что мне это назвать? Поскольку это довольно большой пакет, мне просто нужно, чтобы он был максимально следить за конвенциями (не догматически!) Так будет читаемо для других разработчиков.

Более подробная информация: Это не то, что связано с контроллерами. Это просто объект, который работает как Zend_form (который консолидирует использование всех других объектов, таких как Zend_Form_Element_x и Zend_Validate в один объект), но я не могу просто назвать его PackageName. Это должно быть packagename_something, и я просто не набрал то, что должно быть. Может быть, «обработчик»? ... Я просто хочу убедиться, что кто-то читает это имя, не запутается в роли во всем пакете :)

Answer 1

Видимо, это FrontController использует синглтон.

FrontController не должен быть реализован как Singleton. Книга не предлагает ничего подобного. Пример в книге использует сервлет для обработчика.

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

Многие люди в настоящее время (в том числе Erich Gamma of Gof Fame) посмотрите на Singleton в качестве запаха кода и препятствуют его использованию. В общей архитектуре Singleton может только ограничить экземпляры внутри текущего запроса, поэтому использование в PHP ограничено. Глобальный доступ к объекту может быть достигнут без рисунка Singleton, либо через (зло) глобальных ключевых слов или статических методов. Глобальный доступ всегда создает ненужное сцепление. Лучшим способом было бы использовать инъекцию зависимости, которая имеет дополнительное преимущество обеспечения меньшего соединения и, следовательно, лучшего обслуживания.

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

Там нет такой конвенции о классах именования Фронт классы для моих знаний. То, что вы описываете, может быть Фасад или а Шлюз хотя. Кроме того, вы уверены, что не можете назвать класс после PackageName? В конце концов, Zend_Form пакет имеет А. Zend_Form класс тоже.

Answer 2

Просто от чисто дизайна вида, звучит так, как будто вы используете это Packagename_front в качестве фасада, когда вы говорите:

Есть один класс, который делает их все полезными

Реализация Фаулера говорит:

Передний контроллер консолидирует все обработку запросов путем канала запросов через один объект обработчика

Это неинципиюрует, что синглтон может использоваться для реализации класса переднего контроллера, но он, безусловно, не ограничивает его его использовать. Он не упоминает это, хотя.

Я не думаю, что важно ли свой синглтон. Просто убедитесь, что его единственный канал для запросов, и вы успешно использовали шаблон. :)

Answer 3

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

Если, однако, ваш код всегда будет убедиться, что он называет конструктор только один раз, то есть комната для вашего объекта неинтефона.

Мои 2 цента здесь, так как я не какой-либо книги или что-то еще.