intérêt des évènements par rapport à un appel classique de méthode

[Olivier Revollat]

Bonjour, j'ai découvert le nouveau système d'évènements de symfony 1.1 et je trouve ça vraiment sympa, par contre je me pose une question bête, mais je suis sur que les réponses m'éclairerons sur le contexte dans lequel il faut utiliser les évènements (et aussi quel type de notification utiliser : notify, notify until, filter, ...).
Je me demande donc betement pourquoi on notifie un evenements :

    $this->dispatcher->notify(new sfEvent($this, 'rest_request.fetch_prepare', array(
      'uri'        => $uri,
      'parameters' => $parameters
    )));

au lieu d'appeler betement une methode :

myTools::fetchPrepare($this, $uri, $parameters);

Au fond, à travers cette question, je voudrais comprendre comment et quand doit-on utiliser le système d'evenements ?
Par exemple, j'ai vu que maintenant pour logger un message, on pouvais utiliser l'evenement 'application.log' mais pourquoi ne pas appeler (comme avant) une méthode statique d'un objet de log ?

Sinon, concrètement j'ai un appli qui en fonction de l'utilisateur connecté doit parfois filter les critère (Criteria propel) pour cela je pourrais faire une méthode statique en passant les bon paramètres et ainsi le tout est centralisé et si je veux modifier le comportement de la méthode j'ai juste à modifier le code à un endroit (DRY)... mais voila, le fait est que je pourrais aussi faire ça avec le système d'evenement (en utilisant un appel 'filter()' sur mon objet Criteria avec les bon paramètres) ...

Donc quel sont les avantages du système d'évènements par rapport à un appel de méthode classique ? j'aimerais comprendre cette différence fondamandale qui me permettra d'utiliser au mieux le système d'evenements de ce fabuleux framework qu'est symfony :)

[Melchior Anarchion]

Bonjour,

Les évenements on plusieurs avantage
- le decouplage des classes: le fait d'utiliser le dispatcher ne rend
ta partie du code dépendante que du dispatcher et pas d'un ensemble de
classe (dans ton exemple MyTools mais ca pourrais en etre d'autre si tu
rajoute plusieur fonction de préparation de la requete en cascade )
- la modulartité / l'extensibilité : dans ton exemple si tu veux
rajouter apres myTools::fetchPrepare($this, $uri, $parameters); un
myToolsSpecial::fetchPrepareSpecial($this, $uri, $parameters);
pour la rajouter il faut modifier le code de ta classe d'origine = bug/
faute de frappe etc , c'est pas tres pratique, voir même des fois tu
n'as pas l'acces a ce bout de code a modifier (application propriétaire
et toi tu code un plugin pour celle ci)
avec un gestionnaire d'évenement il suffit d'enregistrer ta classe pour
ecouter cet évenement et elle sera appeler automatiquement par le
gestionnaire d'évenement.

si tu veux plus re renseignement, il faut lire la doc sur le design
pattern observateur.

cordialement seb.



Olivier Revollat a écrit :

[Olivier Revollat]

super merci ... tu aurait un bon lien sur ce design pattern 'observer' ??