clase - getinstance php
Práctica recomendada en clases singleton de PHP (3)
Posible duplicado:
¿Quién necesita singletons?
Siempre escribo con respecto a las mejores prácticas , pero también quiero entender por qué una cosa determinada es una mejor práctica .
He leído en un artículo (desafortunadamente no recuerdo) que las clases singleton son preferidas para ser creadas, en lugar de estar hechas con funciones estáticas y accedidas con el operador de resolución de alcance (: :). Entonces, si tengo una clase que contiene todas mis herramientas para validar, en resumen:
class validate {
private function __construct(){}
public static function email($input){
return true;
}
}
Me han dicho que esto se considera mala práctica (o al menos advertido contra), debido a cosas como el recolector de basura y el mantenimiento. Entonces, lo que las críticas de la "clase singleton como métodos estáticos" quieren, es que instanciar una clase, estoy 100% seguro de que solo crearé una instancia una vez. Para mí, parece hacer un "doble trabajo", porque está todo listo allí. ¿Qué me estoy perdiendo?
¿Cuál es la opinión sobre el asunto? Por supuesto, no es un asunto de vida o muerte, pero uno también podría hacer una cosa de la manera correcta, si la opción está ahí :)
Bueno, esto no es en realidad un singleton; un singleton asegura que solo tiene una sola instancia de una clase, y no hay ningún método aquí que recupere una única instancia de Validate. Su diseño aquí parece ser una clase estática. Esto no causará un problema con el recolector de basura (al menos el código que ha colocado aquí), porque esto se cargaría en la memoria sin importar qué.
Un ejemplo de clases singleton en php:
Crear el patrón de diseño Singleton en PHP5: Ans 1:
Crear el patrón de diseño Singleton en PHP5: Ans 2:
Singleton is considered "bad practice".
Principalmente debido a esto: ¿cómo se prueba duro el patrón de registro o singleton en PHP?
¿Quieres leer más? :
Un diagrama de decisión Singleton ( source ):
Un objeto singleton es un objeto que solo se instancia una vez. Eso no es lo mismo que el Patrón de Singleton , que es un Patrón (Anti-) de cómo escribir una clase que solo se puede instanciar una vez, Singleton ( S grande al principio):
"Asegúrese de que una clase tenga solo una instancia y proporcione un punto de acceso global a ella".
En lo que respecta a PHP, normalmente no es necesario implementar el patrón Singleton. De hecho, debes evitar hacer eso cuando solicites las mejores prácticas , porque es una mala práctica .
Además, la mayoría de los ejemplos de código PHP que se encuentran son implementaciones medio listas del patrón que descuidan cómo funciona PHP. Estas implementaciones falsas no se ajustan a la "garantía" en el patrón.
Esto también dice algo: a menudo eso no es necesario. Si una implementación descuidada ya hace el trabajo sin siquiera acercarse a lo que es el patrón, el patrón incorrecto se ha utilizado para la situación, está empezando a convertirse en un Anti-Patrón .
En PHP, normalmente no hay necesidad de garantizar a toda costa que una clase tenga solo una instancia, las aplicaciones PHP no son tan complejas como las que necesita (por ejemplo, no hay múltiples subprocesos que puedan necesitar referirse a una instancia atómica).
Lo que a menudo queda es el punto de acceso global a la instancia de la clase, que es para lo que la mayoría de los desarrolladores de PHP (mal) usan el patrón. Como se lo conoce hoy en día, el uso de tales "Singletons" lleva a los problemas estándar del estado estático global que introducen complejidad en su código en múltiples niveles y reducen la reutilización. Como programador, pierde la capacidad de usar su código de manera flexible. Pero la flexibilidad es una técnica muy importante para resolver problemas. Y los programadores están resolviendo problemas todo el día.
Entonces, antes de aplicar un Patrón de Diseño, los pro y los contra deben ser evaluados. Solo el uso de un patrón con más frecuencia no es útil.
Para empezar, diría que simplemente escriba sus clases y cuide cómo y cuándo se crean instancias en alguna otra parte de la lógica de la aplicación para que las cosas se mantengan flexibles.