Considere una aplicación que permita que los complementos reaccionen a su flujo de programa.
Conozco 2 formas de lograr esto: ganchos y eventos
1. Ganchos
Use llamadas para vaciar funciones dentro del flujo del programa principal. Estas funciones pueden ser anuladas por complementos.
Por ejemplo, Drupal CMS implementa ganchos que están disponibles para módulos y temas. Aquí hay un ejemplo de cómo se implementa hook en una función file_copy .
function file_copy(stdClass $source, $destination = NULL, $replace = FILE_EXISTS_RENAME) {
// ... [File copying routine]
// Inform modules that the file has been copied.
module_invoke_all('file_copy', $file, $source);
return $file;
// ...
}
Un módulo puede implementar una modulename_file_copy($file, $source)función que será llamada por module_invoke_allin file_copy. Una vez que finalice esta función, file_copyse reanudará la ejecución.
2. Eventos
Haga que la aplicación envíe eventos, que los complementos pueden escuchar. Después de recibir un evento al que se ha suscrito, un complemento interceptará el flujo del programa y realizará las operaciones necesarias.
Por ejemplo, un complemento de la galería jQuery Fotorama implementa varios eventos . Como ejemplo, aquí hay una parte de su showmétodo que dispara el fotorama:showevento.
that.show = function (options) {
// ... [show the new frame]
// [fire the event]
options.reset || triggerEvent('show', {
user: options.user,
time: time
});
// ... [do lots of other stuff with navigation bars, etc.]
};
Un script puede escuchar este evento y hacer algo cuando se dispara:
$('.fotorama').on(
'fotorama:show',
function (e, fotorama, extra) {
console.log(e.type + (extra.user ? ' after user’s touch' : ''));
console.log('transition duration: ' + extra.time);
}
);
PREGUNTA
¿Hay otras formas convencionales de implementar dicho comportamiento de complemento?
Si no es así, ¿cuándo se deben usar ganchos y cuándo se deben usar eventos? Teniendo en cuenta que el objetivo final es hacer que el código sea más fácil de mantener y leer, tanto desde la aplicación como desde la perspectiva del desarrollador del complemento.
Definitivamente eventos, permite la abstracción necesaria ya en el nivel arquitectónico.
No espere que alguien que escriba un complemento lo haga de manera documentada o de alguna manera correcta. He mantenido una API bien documentada con millones de usuarios y, por una experiencia muy dolorosa, puedo decirle que básicamente nadie lee la documentación y casi nadie usa la API correctamente.
Tome el siguiente ejemplo con ganchos: tiene un sistema donde se ejecutan 20 complementos. Uno de esos complementos llama al
file_copymétodo en la forma en que está documentado y espera un resultado tal como está documentado. Pero algún otro complemento ha enganchado esa función y, por lo tanto, uno de los siguientes problemas causa un bloqueo o mal funcionamiento:Si hace lo mismo que anteriormente con eventos con los mismos problemas dentro de esos complementos, sucede lo siguiente:
fuente
La herencia puede ser una opción.
Aparte de los ganchos, la herencia no necesita definiciones de métodos adicionales, y no hay pérdida de rendimiento por llamar al método vacío en caso de que no haya nada conectado.
Además de los eventos, la herencia tampoco necesita un código adicional para la invocación de eventos.
Sin embargo, la herencia funciona mejor si solo hay un complemento que modifica un tipo de comportamiento. Si necesita muchos complementos, el segundo debería derivarse del primero, etc., lo que no es apropiado.
fuente
Definitivamente eventos. Permite que su arquitectura sea más ampliable.
Imagine lo que sucederá si necesita colocar su complemento en una máquina separada, por ejemplo. Uso de eventos: solo tendrá que modificar un pequeño código de paz para que su evento se base en la red.
fuente