PHP Écouteur d'Événement de meilleures pratiques de mise en œuvre

Je suis en train de créer un CMS comme système en PHP. ce qui le rend aussi modulaire et extensible que possible.

Quelqu'un pourrait-il m'offrir la meilleure pratique de scénario de la création d'un écouteur d'événement système en PHP (une version très simplifiée de Drupal système par exemple), la création de crochets et de les mettre en œuvre dans un court exemple serait aussi agréable.

InformationsquelleAutor H.Josef | 2010-12-17
  1. 132

    Bien, il n'y a vraiment trois façons différentes de le faire à partir d'une perspective de mise en œuvre (à noter que ces OO sont des modèles de conception, mais vous pourriez les mettre en œuvre fonctionnelle ou de la procédure si vous voulais).

    1. Modèle Observateur

    Vous pouvez mettre en œuvre la Modèle Observateur. Fondamentalement, vous auriez chaque chose qui peut déclencher des événements plus être un sujet. Puis les classes/code que vous voulez écouter de la lie ce qu'elle veut écouter de la en particulier. Donc, disons que vous avez un contrôleur appelé Foo. Si vous voulais l'écouter, on pourrait appeler $fooController->attach($observer);. Ensuite, chaque fois que le contrôleur voulait dire quelque chose, elle distribue l'événement à tous les observateurs.

    C'est vraiment bien adapté pour un système de notification (pour prolonger ce que les classes sont en train de faire). Ce n'est pas aussi bien adapté à la modification du comportement de code en temps réel.

    2. Décorateur Modèle
    Vous pouvez également mettre en œuvre les Décorateur Modèle. Fondamentalement, vous prenez l'objet que vous souhaitez modifier, et "enveloppe" dans un nouvel objet qui fait ce que vous voulez changer. C'est vraiment bien adapté pour la modification et l'extension du comportement (puisque vous pouvez choisir de remplacer la fonctionnalité de la enveloppé de classe).

    Cela fonctionne très bien si vous avez des interfaces définies et s'attendre à des objets pour les rendre conformes à eux. Si vous n'avez pas d'interfaces (ou de ne pas les utiliser correctement), la plupart de ce qui le décorateur modèle peut faire pour vous sera perdu.

    Notez également que ce n'est vraiment pas une façon de faire les événements, c'est une façon de modifier le comportement des objets.

    3. Médiateur Modèle

    Vous pouvez également utiliser un Médiateur. Fondamentalement, vous auriez un médiateur qui conserve la trace de vos auditeurs. Lorsque vous voulez déclencher un événement, vous pouvez envoyer l'événement pour le médiateur. Le médiateur peut garder la trace de qui l'écoute objets souhaitez recevoir cet événement, et de passer le message correctement.

    Cela a l'avantage d'être central. Sens de plusieurs expéditeurs pouvez envoyer le même événement, et pour les auditeurs, il n'est pas de faire une différence qui l'a envoyé...

    J'ai développé ce sujet dans un billet de blog.

    • Pour une réelle mise en œuvre d'explorer, WordPress implémente le Pattern observer à l'aide de add_action et quelques autres choses. Ce n'est pas beau mais il a tendance à travailler.
    • C'est le Médiateur, le patron, pas un modèle Observateur. Tout moment vous n'êtes pas attachés à la chose que vous voulez écouter directement, c'est le médiateur de modèle. Mais c'est un exemple de procédure de la mise en œuvre d'un modèle de conception OO... c'est Donc un très utile commentaire...
    • Merci pour la clarification, beaucoup apprécié.
    • merci pour l'explication détaillée, je me demande si vous pouvez me donner un simple exemple concret de l'Observateur modèle
    • Merci pour cette réponse et votre article lié
    InformationsquelleAutor ircmaxell
  2. 33
    /*
 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;
    }
}
    • Simple et efficace. Certains utilisateurs préfèrent call_user_func_array à briser le $args dans individuellement transmis variables au lieu d'un tableau comme seul paramètre. Grâce Erwinus.
    • Je sais que vous demande un objet de la Fermeture, mais pourquoi? Vous pouvez également consulter une méthode de classe qui n'est pas anonyme. Peut-être que vous voulez l'appeler une fonction normale/méthode de trop.
    • Si vous n'êtes pas d'accord, le changer si vous le souhaitez, la source est gratuit 😉
    • N'UTILISEZ PAS STATIQUE. Ce code va être dur de se moquer ou de tester à l'avenir. Même extension sera limité. (Elle est aussi en rupture de SOLIDES principes)
    • Précédemment vous avez modifié le code (et ça ne fait aucun sens du tout) et maintenant, vous allez hurler de nouveau. C'est bien que vous n'êtes pas d'accord, astuce: Ne l'utilisez pas.
    • Désolé de crier. J'ai pensé que Vous ne voyez pas mon changement. Mais Vous venez de .l'ignorer. Ne comprends pas pourquoi ? Veuillez expliquer. Votre Idée est ok, mais la mise en œuvre....

    InformationsquelleAutor Codebeat
  3. 13

    C'est la façon dont je l'ai fait dans un certain nombre de projets

    Tous les objets sont créés avec une fonction constructeur au lieu de new opérateur.

     $obj = _new('SomeClass', $x, $y); //instead of $obj = new SomeClass($x, $y);

    cela a de nombreux avantages par rapport à raw new, à partir d'une gestion des événements de point de vue, il est important que _new() maintient une liste de tous les objets créés.

    Il y a aussi une fonction globale send($message, $params) qui itère si cette liste et, si un objet expose une méthode "on_$message", les appels à cette méthode, en passant 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), $_);
}

    Ainsi, par exemple, send('load') appellera on_load méthode pour chaque objet qui l'a défini.

    • Wow...très moyen astucieux de le faire!
    InformationsquelleAutor user187291
  4. 4

    Si vous utilisez PHP 5.3 (et ainsi avoir accès à de riches fermetures), l'événement/filtres de système de Lithium est ce que j'avais à utiliser comme base pour AOP conception en PHP.

    • -1 car ce n'est pas vraiment répondre à la question à portée de main de FAÇON à créer un écouteur d'événement de la bibliothèque. Cela aurait dû être un commentaire.
    • +1 depuis le Lithium est un excellent exemple de la façon de faire des événements de/à l'écoute. C'est un peu difficile à obtenir votre tête autour de la première fois, mais il est extrêmement puissant: Un article utile à ce sujet, Source.
    • Conjuguant inspiration de Lithium avec des filtres de flux, un jeton de réflexion, décorateurs, pointcuts et de fermetures, à partir de PHP5.4 dans un seul endroit les résultats dans le vrai AOP cadre: Aller! AOP PHP, source
    InformationsquelleAutor scoates