Vous ne trouvez pas de réponse à votre problème ? Alors posez la question dans le forum. Souvenez-vous qu'il n'y a jamais de question bête, mais rester dans l'ignorance parce que l'on n'ose pas poser une question, ça c'est une erreur !

PHP / ARCHITECTURE EVENEMENTIELLE - PARTIE 1


Information sur le tutorial

Catégorie :Class et Objet ( POO ) Date de création : 09/06/2008 21:37:30 Vu : 6 159 fois

Note :
Aucune note

Commentaire sur cette source (4)
Ajouter un commentaire et/ou une note

Description

Vous le savez déjà surement, mais chaque instruction est interprétée (ou compilée) sous la forme d'opérations basiques, avec un ensemble de niveaux de langages et plus le niveau est base et plus il se rapproche des opérations envoyées au processeur (l'assembleur n'étant pas vraiment le tout premier niveau mais il en est très proche).

Je souhaite vous attirer l'attention sur ce détail pour que vous preniez conscience du fait que ce soit un mono ou biprocesseur, ou encore un système en multithreading rien ne s'exécute simultanément sur une machine (heureusement de nos jours on ne s'en rend même pas compte J )

En « contradiction » avec mes propos, l'événement en informatique consiste non pas dans une exécution linéaire (du point de vue du développeur haut niveau) mais d'une exécution basée sur une interaction définissant un ensemble de points d'entrées d'exécution linéaires (traitements) communément appelés événements.

Du coup voici le dilemme : qu'est ce que c'est qu'un événement dans une exécution linéaire.

Tutorial

Définition :

Pour ma part l'événement est un ou plusieurs point(s) d'entrée(s) (fonction(s) par exemple) déclenché / appelé à partir d'une interaction (changements d'états).

Cas pratique :

Du coup l'approche sous PHP devient différente. Au lieu d'avoir par exemple :

<?php  
            If (isset($_POST['submit'])) { 
                        // TRAITEMENTS 
            }  
?><form method="post"><input type="submit" name="submit" /></form>

On pourrait avoir :

<?php 
            class myForm extends ... { 
                        function onSubmit() { 
                                   // TRAITEMENTS 
                        } 
            }  
?><form method="post"><input type="submit" name="submit" /></form>  

Vous vous dites que l'approche est sympa mais qu'au fond les deux méthodes se valent. Eh bien non, la différence entre la première et la seconde méthode (autre que la forme) c'est que le traitement et l'interception sont séparées (le principe de base l'informatique ... pour mieux régner ...). On part du même principe pour en démontrer l'intérêt :  

<?php 
            include('machin.php'); 
            If (isset($_POST['submit'])) { 
                        // TRAITEMENTS 
            }  
?><form method="post"><input type="submit" name="submit" /></form>

Et machin.php contiendra ceci :

<?php 
            If (isset($_POST['submit'])) { 
                        // AUTRES TRAITEMENTS 
            }  
?>

Et on fait des tonnes de fichiers (similaires à cet exemple) basés sur le traitement d'un ensemble de formulaires complexes pour des règles métier complexes. Vous n'y pouvez rien, c'est ce qu'on appelle du code spaghetti.

Du coup en POO événementielle on aurait ceci :

<?php 
            include('machin.class.php'); 
            class myForm extends machin { 
                        function onSubmit() { 
                                   // TRAITEMENTS 
                        } 
            }  
?> <form method="post"><input type="submit" name="submit" /></form>

Et le fichier machin.class.php pourrait contenir ceci :

<?php 
            class machin extends ... { 
                        function onFormSubmit() { 
                                   // AUTRES TRAITEMENTS 
                        } 
            }
?>

L'avantage consiste évidement d'une part à ne pas se soucier de l'interception, et de laisser les objets spécialisés s'en charger, et d'une autre part, imaginez-vous changer le nom d'un tel bouton dans votre script.

Autre chose, vous remarquerez que j'ai surchargé la classe myForm et que je n'ai pas utilisé la surcharge de fonction. Tout ceci est volontaire, je vous l'explique par la suite.

Outro partie 1 :

Les exemples de ce tuto sont purement illustratifs, et ne comportent pas l'ensemble du code ou bien ne rentrent pas dans une proposition de système concréte.

Dans le prochain tuto je vous propose de découvrir l'architecture objet liée à un système événementiel et voir concrètement son utilisation par du code.

09 juin 2008 21:41:55 :
sauts de ligne
signaler à un administrateur
Commentaire de dfs le 18/06/2008 11:15:43

cooool
mais mon ami
c 1 peu dur a mon cerveau
ou je trouve de l'expliq
merci
@+

signaler à un administrateur
Commentaire de aKheNathOn le 20/06/2008 01:03:46

bonjour mon ami, c'est la partie 1 du tuto, et je prépare une partie 2 (mais en ce moment j'ai pas de temps).

Dans la seconde partie j'explique ça en plus technique et concret donc ça devrait aller.

Sinon pour résumer le tout en une phrase le principe c'est de proposer un modéle en php un peu comme le modéle MVC mais là l'approche est événementielle. Les événements existent déjà en DOTNET ou JAVA mais c'est pas natif en PHP.

L'avantage de faire de la prog événementielle c'est d'étendre les capacités d'extensibilité de ton système : tu décentralises les traitements pour chaque type d'évenement sans passer par la prog poo classique : héritage / surcharge.

Un exemple tu as une classe boutton qui intercepte quand tu valide ton formulaire. Pour spécifier une action, en POO tu vas définir une classe héritant de ce boutton et redéfinissant une fonction genre onclick (dslé pr les puristes c la methode compatible sous PHP4).

En événementiel, tu crées une instance de boutton puis tu lui dit que à l'évenement onClick il doit executer telle fonction. La gestion de la pille d'appels est beaucoup plus souple que celle qu'un empilement d'héritages ou la contrainte est justement l'héritage alors qu'en PHP on ne peut même pas faire de l'héritage multiple (je ne considére pas les interfaces en terme d'héritage car c'est pas interessant car pas de surcharge).

La partie méthodo est un peu abstraite, mais promis la suite du tuto sera technique et plus concréte.

signaler à un administrateur
Commentaire de malalam le 28/06/2008 12:30:18 administrateur CS

Hello Akhe,

moi je n'ai rien dit parce que j'attends la 2de partie :-)
L'approche est intéressante pour le moment.

signaler à un administrateur
Commentaire de jadu le 13/04/2009 20:30:01

y a-t-il eu une seconde partie ????

Ajouter un commentaire



Nos sponsors

Sondage...

CalendriCode

Juillet 2009
LMMJVSD
  12345
6789101112
13141516171819
20212223242526
2728293031  

Consulter la suite du CalendriCode

Comparez les prix Nouvelle version

Photothèque Nouveau !



Développement réalisé par Nicolas SOREL (Nix) avec l'aide de : Cyril DURAND et Emmanuel (EBArtSoft), Merci à Vincent pour ses précieux conseils
CodeS-SourceS.com© Toute reproduction même partielle est interdite sauf accord écrit du Webmaster
CodeS-SourceS.com© est une marque déposée tous droits réservés
Temps d'éxécution de la page : 0,094 sec

Google Coop CodeS-SourceS Google Coop CodeS-SourceS


Certaines images présentes sur le site (notament certains avatars) sont issues des collections IconShock, donc si vous souhaitez utiliser ces icons vous devez les acheter, ne les copiez pas et ne utilisez pas dans vos sites et applications sans les avoir commandé.