Implementación de las mejores prácticas de PHP Event-Listener
doctrine events (5)
Así lo hice en un par de proyectos.
Todos los objetos se crean con una función constructora en lugar de un new operador.
$obj = _new(''SomeClass'', $x, $y); // instead of $obj = new SomeClass($x, $y);
Esto tiene muchas ventajas en comparación con lo new , desde el punto de vista del manejo de eventos, es importante que _new() mantenga una lista de todos los objetos creados.
También hay una función global send($message, $params) que itera a través de esta lista y, si un objeto expone un método "on_ $ mensaje", llama a este método, pasando params:
function send() {
$_ = func_get_args();
$m = "on_" . array_shift($_);
foreach($_all_objects as $obj)
if(method_exists($obj, $m))
call_user_func_array(array($obj, $m), $_);
}
Entonces, por ejemplo, send(''load'') llamará al método on_load para cada objeto que lo tenga definido.
Estoy tratando de crear un sistema similar a CMS en PHP. Haciéndolo lo más modular y extensible posible.
Alguien podría ofrecerme el mejor escenario para crear un sistema de escucha de eventos en PHP (una versión muy simplificada del sistema Drupal, por ejemplo), crear enlaces e implementarlos en un breve ejemplo también sería bueno.
Bueno, en realidad hay tres formas diferentes de hacerlo desde una perspectiva de implementación (tenga en cuenta que estos son patrones de diseño OO, pero podría implementarlos funcionalmente o de manera procesal si quisiera).
1. Patrón del observador
Puede implementar el patrón de observador . Básicamente, tendrías que cada cosa que puede elevar eventos sea un tema. Entonces las clases / código que desea escuchar se unen a lo que quiere escuchar específicamente. Así que digamos que tienes un controlador llamado Foo . Si desea escucharlo, puede llamar a $fooController->attach($observer); . Luego, cuando el controlador quisiera decir algo, enviaría el evento a todos los observadores.
Esto es realmente adecuado para un sistema de notificación (para extender lo que están haciendo las clases). No es tan adecuado para modificar el comportamiento del código en tiempo real.
2. Patrón de decorador También puedes implementar el Patrón de decorador . Básicamente, toma el objeto que desea modificar y lo "envuelve" en un nuevo objeto que hace lo que desea cambiar. Esto es realmente adecuado para modificar y ampliar el comportamiento (ya que puede anular selectivamente la funcionalidad de la clase ajustada).
Esto funciona muy bien si ha definido interfaces y espera que los objetos se ajusten a ellas. Si no tiene interfaces (o no las usa correctamente), la mayoría de lo que el patrón de decorador puede hacer por usted se perderá.
También tenga en cuenta que esto realmente no es una forma de hacer eventos, es una forma de modificar el comportamiento de los objetos.
3. Patrón de mediador
También puede utilizar un Mediator . Básicamente, tendrías un mediador global que realiza un seguimiento de tus oyentes. Cuando desea desencadenar un evento, envía el evento al mediador. El mediador puede entonces hacer un seguimiento de qué objetos escuchados desean recibir ese evento y transmitir el mensaje correctamente.
Esto tiene la ventaja de ser central. Lo que significa que los remitentes múltiples pueden enviar el mismo evento, y para los oyentes no importa quién lo envió ...
No estoy seguro de por qué las personas en PHP piensan que ganan algo de los oyentes. Pregunta simple: si estoy buscando desarrolladores de PHP simplemente hago una pregunta: ¿cuáles son los problemas y las limitaciones de MVC?
Si no puede responder eso, no debería considerar la implementación de escuchas o la implementación de un marco.
Siguiente Conoce tu idioma. PHP es un solo hilo, una sola compilación. Significado de la memoria y los objetos son específicos del hilo. Como resultado, los escuchas y otros objetos de estar vivo en Java / C # nunca se deben usar en php, ya que tienden a ser costosos de construir y complicar la aplicación sin obtener el valor suficiente para justificarlos.
Los Frameworks NO son compatibles, y desde hace 2 años el líder de PHP dijo que no tenían la intención de soportar Frameworks para PHP. Esto significa que para que un marco funcione la mitad de lo bueno que PHP nativo con PEAR, debe implementar docenas de complementos que ocupan memoria, complican el desarrollo y ofuscan el código sin ningún beneficio.
El desarrollo de PHP estándar es más rápido y más fácil de usar que la mayoría de los marcos para PHP. Hay varias bibliotecas PEAR que pueden ayudarlo enormemente en su tarea. No intente ser un desarrollador multiproceso en un sistema de un solo hilo, su servidor no tiene un valor real.
Si necesita comunicación entre subprocesos, suelte PHP y desarrolle en un lenguaje de subprocesos múltiples.
No utilice la tecnología debido a una palabra BUZZ. MVC se usa demasiado y el 99% del tiempo se usa incorrectamente. Los resultados van desde sistemas lentos, a estructuras de datos deficientes / validación. Los oyentes son los mismos, sabe lo que es antes de usarlo.
La primera pregunta antes de cómo lo hago? Debería ser por qué debería? Conozca su tecnología, las tendencias enseñan malos hábitos y los desarrolladores de mierda.
Lo sentimos, la caja de jabón se ha acabado, simplemente está cansada de correr a la carrera de los desarrolladores de PHP que escriben loros enlatados e ideologías sin pensar en ellas. Esta es la razón por la que los desarrolladores de Java se burlan de los desarrolladores de PHP, porque están tratando de usar la tecnología para la que su lenguaje no fue diseñado, y el creador dijo que no tenía intención de apoyar.
Hay grandes desarrolladores de PHP por ahí, pero no los que intentan usar frameworks ajustados como Zend Framework, o tecnologías como Domain Controllers u Listeners.
/*
Example 1:
event::bind(''blog.post.create'', function($args = array())
{
mail(''[email protected]'', ''Blog Post Published'', $args[''name''] . '' has been published'');
});
Example 2:
event::trigger(''blog.post.create'', $postInfo);
*/
class event
{
public static $events = array();
public static function trigger($event, $args = array())
{
if(isset(self::$events[$event]))
{
foreach(self::$events[$event] as $func)
{
call_user_func($func, $args);
}
}
}
public static function bind($event, Closure $func)
{
self::$events[$event][] = $func;
}
}