Php / architecture evenementielle - partie 1
Php / architecture evenementielle - partie 1
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. Plus le niveau est bas, 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 attirer votre attention sur ce détail pour que vous preniez conscience du fait que ce soit un mono ou bi-processeur, 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.
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"></form>
On pourrait avoir :
<?php
class myForm extends ... {
function onSubmit() {
// TRAITEMENTS
}
}
?><form method="post"></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"></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"></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.
- Php / architecture evenementielle - partie 1
- Javascript partie entiere ✓ - Forum Java
- Php table - Conseils pratiques -PHP
- "Php version 4.4.5" "build date" "server api" "php variables" ✓ - Forum PHP
- Php protected ✓ - Forum PHP
- Php version 4.4.6 build date server api php variables - Forum PHP