¿Deberían todas las clases frontales usar Singleton?

Question

Considere los patrones de la arquitectura de aplicaciones empresariales de Martin Fowler y el patrón del controlador frontal: http://martinfowler.com/eaacatalog/frontcontroller.htmlAparentemente, usa el patrón Singleton. Bueno, tengo un paquete de clases en la aplicación PHP que funcionan juntas (como el paquete de controlador de Zend) y hay una clase que las hace todos utilizables y, dado que se asemeja a muchos de los conceptos del controlador frontal, lo llamé PackageName_Front. Pero no debería ser una clase de singleton (a diferencia del controlador frontal), así que ¿todavía dejo que tenga el nombre del frente? Si no, ¿cómo lo llamo? Dado que es un paquete bastante grande, solo necesito que siga las convenciones tanto como sea posible (¡no de manera dogmática!) Por lo tanto, sería legible para otros desarrolladores.

Más información: no es nada relacionado con los controladores. Es solo un objeto que funciona como Zend_Form (que consolida el uso de todos los otros objetos como Zend_Form_element_X y Zend_Validate en un objeto) pero no puedo nombrarlo PackageName. Tiene que ser PackageName_Something, y no soy un padre de lo que algo debería ser. ¿Quizás "Handler"? ... Solo quiero asegurarme de que cuando alguien lea su nombre, no se confunde sobre su papel en todo el paquete :)

Answer 1

Aparentemente, FrontController Utiliza el patrón de singleton.

FrontController no tiene que implementarse como Singleton. El libro no sugiere algo como esto. El ejemplo en el libro usa un servlet para el controlador.

El hecho de que una clase solo sea necesaria una vez en una aplicación no justifica su implementación como un singleton. Le falta el propósito del singleton que es hacer cumplir Una clase solo puede tener una instancia y proporcionar acceso global a él. Si necesita una instancia particular solo una vez, considere Solo crea uno en cambio.

Muchas personas hoy en día (incluido Erich Gamma de la fama de GoF) ven el singleton como un olor a código y desalientan su uso. En una arquitectura de nada compartido, el singleton solo puede restringir las instancias dentro de la solicitud actual de todos modos, por lo que el uso en PHP es limitado. El acceso global a un objeto se puede lograr sin el patrón Singleton, ya sea a través de la palabra clave global (malvada) o los métodos estáticos. El acceso global siempre crea un acoplamiento innecesario. La mejor manera sería utilizar la inyección de dependencia, que tiene el beneficio adicional de proporcionar menos acoplamiento y, por lo tanto, una mejor capacidad de mantenimiento.

Entonces, ¿todavía dejo que tenga el nombre del frente? Si no, ¿cómo lo llamo? Como es un paquete bastante grande, solo necesito que siga las convenciones tanto como sea posible (¡no de manera dogmática!)

No existe tal convención sobre las clases de nombres Frente clases que yo sepa. Lo que describe podría ser un Fachada o Puerta aunque. Además, ¿estás seguro de que no puedes nombrar la clase después del nombre de PackageName? Después de todo, el Zend_Form El paquete tiene un Zend_Form clase también.

Answer 2

Solo desde una vista puramente de diseño, parece que estás usando ese paquete de paquete_front como fachada cuando dices:

Hay una clase que los hace a todos utilizables

La implementación del patrón de Fowler dice:

El controlador delantero consolida todo el manejo de solicitudes canalizando las solicitudes a través de un objeto de controlador único

Esto insinúa que un singleton podría usarse para implementar la clase de controlador frontal, pero ciertamente no lo limita a usarlo. Sin embargo, no lo menciona explícitamente.

No creo que sea importante si es un singleton o no. Solo se asegura de que sea el único canal para las solicitudes, y habrá utilizado con éxito el patrón. :)

Answer 3

La idea detrás del patrón Singleton es asegurarse de que solo haya una instancia de un objeto que se supone que solo existe en una sola instancia. El controlador frontal cae muy bien en esta categoría, por lo que, tal vez, sería prudente hacer que siga un patrón de singleton.

Sin embargo, si su código siempre se asegurará de que llame al constructor solo una vez, entonces hay espacio para su objeto de patrón que no es de singleton.

Mis 2 centavos aquí, ya que no soy un autor de libro o algo así.