Bonjour,

J'ai décidé de prendre le taureau par les cornes et d'arrêter la programmation procédurale mwhouaheinheinn

et pour se faire j'me suis dit pourquoi ne pas gérer ma page html comme un objet, que la couleur du fond de page soit un attribut/propriété et que afficher cette couleur soit la méthode.

Voici ce que j'ai fait, punaise que c'est abstrait à mes yeux :

Ma classe page

<?php 
	class Page
	{
	private $couleur;
	
		afficherCouleur()
		{
			return $this->couleur;	
		}
		
	}
?>

Ma page index.php

<?php 
require_once("Page.php");
	$page = new Page("#FF0");
	$page->afficherCouleur();
?>

mais bon les néophytes et autres comprendront déjà que mmhmmmm c'est pas gagné...

Quelqu'un peut m'aiguiller ?

Mega

déjà la sytaxe n'est pas bonne, y'a pas de function devant afficherCouleur, donc t'as même pas testé ton propre code

Je pense que pour aborder la POO, ton exemple est très mauvais.

Essaye de voir la POO comme la modélisation du métier de ton application.
Le HTML n'est que la présentation des données gérées par le métier.

Pose toi la question suivante : à quoi sert mon application, quelles sont les données qu'elle manipule ?
Une fois que tu auras cette réponse, tu auras une idée de tes objects, et tu te rendra compte que la page HTML n'en est pas un.

Une fois que tu seras plus familier avec ces notions de base, tu pourras commencer à percevoir toute ton application sous un oeil OO, mais commencer par là me semble dangereux pour tes neurones et ton courage.

Bonjour,

déjà la sytaxe n'est pas bonne, y'a pas de function devant afficherCouleur, donc t'as même pas testé ton propre code

Si si stealth35, vu que j'avais une erreur, "simple" oubli.

Je pense que pour aborder la POO, ton exemple est très mauvais.

Essaye de voir la POO comme la modélisation du métier de ton application.
Le HTML n'est que la présentation des données gérées par le métier.

Pose toi la question suivante : à quoi sert mon application, quelles sont les données qu'elle manipule ?
Une fois que tu auras cette réponse, tu auras une idée de tes objects, et tu te rendra compte que la page HTML n'en est pas un.

Une fois que tu seras plus familier avec ces notions de base, tu pourras commencer à percevoir toute ton application sous un oeil OO, mais commencer par là me semble dangereux pour tes neurones et ton courage.

Je suis courageux et volontaire tu sais...Je n'ai pas d'exemple concret sous la main. Tu en as un ? La page html quand elle fait partie d'un CMS sous forme de template peut être gérée comme telle, non ? "Essaye de voir la POO comme la modélisation du métier de ton application.", c'est à dire ? Aurais-tu un exemple ? J'ai déjà vu un fichier PDF généré à la volée être un objet, tu trouves ça déconnant ?

Pouvez-vous tout de même m'aider à finir ce "script" pour la forme ?

++

Mega

Par exemple, tu parles de CMS, donc la données métier, c'est le contenu de la page, pas la page.
Tu dois commencer par modéliser comment gérer le texte, les images, les vidéos, le template générique avant de penser la couleur de fond ou l'ordre des balises head

Ok alors j'aimerai avoir votre point de vue sur le cas suivant.

Imaginons je passe à Lyon et je vois sur une affiche "Aujourd'hui ateliers découverte javascript et PHP avec stealth35 et Zeus. si vous êtes intéressé par l'un ou l'autre...". Pour s'inscrire nous avons un formulaire. Comment en objet d'un point de vue théorique géreriez-vous la chose, l'inscription, l'affichage des données...etc.

Mercis pour vos contributions.

Cdlt,

Mega

je trouve que la doc est plutôt bien faite y'a des exemples pour chaque cas :
http://www.php.net/manual/fr/language.oop5.php

Salut, je crois que tu ne te poses pas la bonne question.

Pour le moment, tu voudrais évoluer vers un style de programmation qui est beaucoup plus « avancé » en PHP et construire ce que tu faisais déjà mais en utilisant la POO sans trop savoir finalement quel en est l'intérêt réel et pratique. Donc je crois qu'il faut commencer par poser les bonnes bases de ce qu'est la POO.

La POO, ce sont des classes. À quoi servent les classes ? À traiter des données. Une classe, c'est un fichier de code qui sera ré-utilisable partout si nécessaire pour traiter un problème récurrent. On parle d'objets parce qu'on tente de faire le parallèle avec des objets de la vie courante qu'on utilise au quotidien. Exemple : tu dois faire tes comptes pour savoir où en sont tes finances, tu as d'un coté des factures payées et de l'autre des notes et des relevés sur tes rentrées. Tu vas donc prendre un objet, en l'occurrence une calculatrice : ici, la calculatrice sera en quelque sorte notre classe. Cette calculatrice a un certain nombre de propriétés et de méthodes. Tu vas appeler des méthodes pour ajouter ou soustraire. Lorsque tu allumes ta calculatrice, ça revient à créer une instance de ta classe. Dans le constructeur, on va définir la valeur de départ et donc on va fixer le solde courant à 0.00. Ensuite, tu as par exemple une rentrée : tu as vendu ton antique Comodore 64 à un collectionneur fou et il t'a donné 1000.00€ : tu vas donc appeler la méthode additionner() en lui passant 1000 en paramètre. La méthode de l'objet va mettre à jour le solde de l'instance en additionnant le solde courant à la valeur du paramètre envoyé. Même chose pour le loyer que tu as payé, tu as dépensé 650.00€, tu appelles la méthode soustraire() en lui passant le montant de 650. Chaque méthode (additionner() ou soustraire() te retourne le solde après l'opération. Le premier appel de méthode t'a donc retourné +1000.00, l'appel de la suivante t'a retourné +350.00 (1000 - 650).

Lorsque tu as terminé tu connais ton solde et tu peux éteindre la calculatrice, ce qui revient à appeler implicitement le destructeur, ce que fait PHP5 très bien, l'instance n'étant plus utilisée, elle est détruite et n'existe plus. Mais bien entendu la classe (ici notre objet calculatrice) est toujours disponible pour la création d'une nouvelle instance.

En résumé, on crée des classes pour se simplifier la vie et surtout traiter des données de façons cohérentes comme des objets : l'important, c'est que chaque objet est indépendant des autres et dispose de ses propres méthodes. C'est comme ça qu'on crée des classes pour faire toutes sortes de choses : se connecter à une base de données, manipuler des requêtes et récupérer, modifier, supprimer ou ajouter des données, ou encore envoyer des courriels, générer des fichiers PDF ou d'autres formats de bureautique, se connecter à un web service et échanger des données avec un autre système, etc, etc.., les possibilité sont innombrables. On pourrait faire tout ça en procédural, mais ce serait beaucoup plus lourd et moins maniable.

Dans un CMS par exemple, demande-toi quels sont les éléments qui reviennent souvent, qui sont éventuellement complexes à traiter alors qu'avec une ou plusieurs classes correctement faites tu pourrais traiter plus simplement en appelant simplement des méthodes paramétrées ou non ?
Quand on crée une classe, je vais schématiser à l'extrême en disant que tu rajoutes des méthodes à celles existant nativement dans le langage. Les méthodes natives traitements des problèmes basiques, et nous on se crée des méthodes complexes qui s'appuient sur ces méthodes basiques pour traiter de façon complexe nos données.

Si tu as saisi globalement le principe, je pense qu'il te reste à répondre à la question posée ci-dessus sur le CMS, ça va t'aider à décortiquer la question et il se trouvera bien un peu de monde ici pour te remettre sur le chemin si tu mets le pied dans un trou

Bonjour à tous,

Ca faisait un p'tit moment Cyrano ...

Merci à toi pour cette explication on ne peut plus claire. J'ai imprimé ton post c'est dire

Dans le cas de cet exemple, tu ne ferais pas appel aux classes si je comprends bien :
"Imaginons je passe à Lyon et je vois sur une affiche "Aujourd'hui ateliers découverte javascript et PHP avec stealth35 et Zeus. si vous êtes intéressé par l'un ou l'autre...". Pour s'inscrire nous avons un formulaire. Comment en objet d'un point de vue théorique géreriez-vous la chose, l'inscription, l'affichage des données...etc."

dans le pire des cas une classe de connexion.

Mega

Attention, PHP n'est ni Java ni C++, ce n'est pas un langage Full Objet, même si théoriquement on pourrait presque complètement programmer en objets.

Pars du besoin fonctionnel : ton exemple indique un formulaire de connexion, des ateliers de programmation sur divers langages et on peut imaginer qu'il y aura probablement aussi un formulaire d'inscription à un atelier ou un autre. Ok, là on a des éléments sur les données qu'on va devoir manipuler dans l'application et des éléments d'ordre fonctionnel. Partant de là, tu vas pouvoir élaborer la structure des données. À plus long terme, tu vas avoir un certain nombre de traitements à effectuer : traitement et validation d'un formulaire, connexion à une base de données, liste des ateliers disponibles donc collecte de données et affichage, filtrage de l'affichage selon le statut de connexion du visiteur, donc gestion de session. Et là, tu peux commencer à entrevoir des objets : session, formulaire, BDD, peut-être templates si tu en utilises pour construire tes pages, tout ça peut être traité comme des objets qui collaboreront plus ou moins directement pour construire l'ensemble des pages.

Et quand je suggère de partir du besoin fonctionnel, j'en arrive aussi à la chronologie de ton développement et je vais reprendre la signature de mere-teresa ici : « Règle n°2 du webmaster : Toujours commencer par le HTML qu'on veut obtenir....toujours ! »

MERCI CYRANO.

Mega


Ps : je ne me lasse pas de ta signature avec ton axe.gif

Ps : je ne me lasse pas de ta signature avec ton axe.gif

Si tu savais le nombre de gens qui ont la chance absolument insolente que j'ignore leur adresse... ça saignerait sévère des fois. Si on me donnait 1€ à chaque fois que je tombe sur une personne qui code comme un vrai goret, je pourrais presque arrêter de bosser