Bonjour,

J'ai essayé quelque chose, le B A BA et je voudrais avoir l'avis de personnes plus confirmées pour m'aider à mieux appréhender la POO.

Imaginons un p'tit back office pour ajouter des news par exemple, des évènements, soyons fous

J'ai fait ceci, mon formulaire d'ajout :
Ma classe :

<?php 
     class Events {
          public $unnom;
		  public $unlieu;
		  public $unedate;
          public function __construct($unnom, $unlieu, $unedate) {  
               $this->unnom = $unnom;  
               $this->unlieu = $unlieu;  
               $this->unedate = $unedate;  
          }
		  
		  function afficher_event(){
		  $retour = "l'évènement ".$unnom." aura lieu à ".$unlieu.", le ".$unedate;
		  echo $retour;
		  }
     }
?>

La page de traitement :

<?php 
include ("Events.php");
$event = new Events($_POST["nom"],$_POST["lieu"],$_POST["date"]);
$event->afficher_event();
?>

Ca ne marche pas génial lol mais est-ce la bonne façon de voir ? Que faudrait-il corriger et si j'ai un appel à la base comme un insert, ou le positionner, dans la classe ?

Merci par avance de votre aide. Je veux commencer par des trucs très basiques complètement inventés pour bien comprendre l'intérêt de la POO, moi le grand procédural

Mega

C'est un bon début

Y a toutefois quelques p'tites choses qui vont pas :

- dans ton formulaire, les noms des champs sont cnom, clieu et cdate, alors que dans traitement.php tu récupères $_POST['nom'], $_POST['lieu'] et $_POST['date']

- dans ta méthode afficher_event(), tu utilises les variables $unnom, $unlieu et $unedate alors que celles-ci ne sont pas définie. En fait, ce sont les attributs de l'instance qu'il te faut afficher : $this->unnom, $this->unlieu et $this->unedate

Pour le reste, pas grand chose à redire (bon je peux toujours trouver à pinailler s'il le faut )

Salut Ryle, ca faisait un moment , toujours fidèle au poste à ce que je vois héhé.

C'est un bon début

Merci

Y a toutefois quelques p'tites choses qui vont pas :

- dans ton formulaire, les noms des champs sont cnom, clieu et cdate, alors que dans traitement.php tu récupères $_POST['nom'], $_POST['lieu'] et $_POST['date']

Pure inattention comme tu t'en doutes pour un procédurier comme moi

- dans ta méthode afficher_event(), tu utilises les variables $unnom, $unlieu et $unedate alors que celles-ci ne sont pas définie. En fait, ce sont les attributs de l'instance qu'il te faut afficher : $this->unnom, $this->unlieu et $this->unedate

Ca marche mieux en effet

Pour le reste, pas grand chose à redire (bon je peux toujours trouver à pinailler s'il le faut )

Ne te prive pas, j'adore ca les remarques constructives

So ?

Mega

Ah non, j'ai pas parlé de remarques constructives, mais bien de pinailleries

Par exemple, mettre les attributs de ta classe en private de façon à ce qu'ils ne puissent pas être modifiés sans passer par le constructeur (ou du moins par le chemin que toi tu auras choisis). Ce n'est pas une généralité, et il peut parfois être utile de les garder public (mais c'est rare ).

En gros, pour le moment, le développeur qui utilise ta classe (car c'est aussi ça l'un des grands avantages de l'objet : partager ) dispose de deux solution pour renseigner la date de l'événement :
soit via le constructeur :

$event = new Events('', '', '01/01/2009');

soit via l'attribut :

$event = new Events('', '', '');
$event->unedate = '01/01/2009';

Le problème c'est que rien ne l'empêche de faire ceci :

$event = new Events('', '', '');
$event->unedate = 'tirelipimpomsurlechiwawa';

Si tu passes l'attribut $unedate à private, le dev ne pourra passer que par le constructeur. Quel intérêt ? et bien tout simplement de pouvoir contrôler les valeurs qu'ils va tenter d'y mettre.

En effet, si tu centralise l'accès à cette variable dans ton constructeur (ou ailleurs) tu peux également y ajouter des contrôles pour par exemple vérifier le format et mettre une valeur par défaut où afficher un message d'erreur lorsque celui-ci n'est pas correct.

Tu t'affranchis ainsi d'un contrôle lorsque tu vas insérer ta date en base de données, d'un contrôle lorsque tu vas vouloir la mettre à jour (ça évite de déranger MySQL avec des valeurs qui ne rentrent pas dans ses tables), d'un contrôle lorsque tu voudras l'utiliser etc. (dans un mktime par exemple) et surtout tu garantis à celui qui va exploiter ton objet que les données qu'il va y trouver sont propres et cohérentes (c'est plus pratique de savoir que la date est toujours au format jj/mm/aaaa que de dépendre du développeur qui l'aura renseigné )

Bon aller, maintenant tu nous fait une méthode qui va enregistrer l'événement en base et une autre qui pour une date donnée va te lister les événements qui y ont lieu

[...]Bon aller, maintenant tu nous fait une méthode qui va enregistrer l'événement en base et une autre qui pour une date donnée va te lister les événements qui y ont lieu

Salut Ryle, que dire : t'es excellent

Les choses paraissent si simples dans tes explications, t'as pas pensé à écrire des bouquins sérieux (à moins que ce soit déjà le cas ) ?

Pour le gestionnaire d'events je vais essayer de m'y coller tiens.

ca va marcher ca va marcher ca va marcher lol

Amicalement,

Mega


J'adore toujours autant ta signature et ton avatar