Bonjour,

Plutôt que de me retrouver comme un sot devant mon PC j'préfère avoir à faire à tes êtres vivants qui sauront me faire partager, je l'espère, leurs avis et connaissances. Je voudrais connaître les avantages, l'utilité de passer par la poo. Pourriez-vous me donner un cas abstrait et concret qui pourrait éclairer mes pauvres neurones ? Je code comme je parle personnellement...

Je vous remercie par avance

Newbinours

Salut, la POO s'oppose pas mal à la programmation procédurale en fait. L'avantage c'est que tu organises ton projet proprement sous formes de différentes classes. C'est assez difficile à expliquer au début et quand on début on a souvent du mal à comprendre l'intéret de la chose, mais il faut s'y mettre pour se rendre compte de toutes les possibilités.

En plus d'avoir un code très structuré, organisé et lisible, la POO permet beaucoup de choses que tu ne peux pas faire autrement : utilisation de propriétés (au lieu de passer par des globales ..), héritage, etc ...

Merci de ta réponse mais c'est, vu mon niveau, un peu flou pour moi tout ça. N'aurais-tu pas sous le coude un exemple abstrait et un autre plus concret pour mieux comprendre les avantages ?
Ne vois pas en moi une honce de fainéantise dans mes recherches c'est juste que je préfère une bonne vieille explication que des lignes et des lignes de codes. J'aime le contact et transmettre comme recevoir des connaissances

Newbinours

En fait, le principe globale, très simplement est le suivant.

En procédural, si tu désires mettre en place un code qui sera utilisé à plein d'endroit dans ton code, tu créé une fonction.
Dans un gros projet, tu te retrouves vite avec des tas de fonctions dans tous les sens qui doivent manipuler des tas de paramètres. Tu remarques qu'il y a des fonctions qui manipulent des données très semblables, avec des paramètres identiques. Par exemple, dans le cas d'une gestion des membres, tu doit vérifier s'il est loggé, lui attribuer des droits, et lui affecter une vente (exemple bateau).
En procédural, tu auras une fonction par action, et à chaque fonction, il faudra que tu lui passes l'identifiant du membre en question.

En objet, tu crée des classes, c'est à dire des représentations des entités que tu gères et tu lui attribue des comportements.
Toujours dans l'exemple de la gestion des membres, tu va créer une classe "membre" qui a comme attribut (des données qui lui appartiennent) son identifiant.
Les comportements que tu lui donnes sont "identifier", "affecterdroit" et "affectervente"

A partir du moment où tu as créé la classe, tu n'appelles plus les fonctions en te demandant quels sont les paramètres, tu créé une instance de ton entités, qui ca récupérer tout seul les attributs voulu, et tu déclenches les comportements.

Du coup, tout le code associé à une entité est dans un même endroit physique, toutes les actions associées à cette entité utiliserons la même méthodologie, ...

Le problème c'est que c'est difficile de donner une explication ... mais pour donner un code simple :
imagine tu dois créer un projet, qui doit être compatible avec MySQL et PostGreSQL (un autre type de base de donnée). Dans ton code tu vas pas te taper des

if ($config_sgbd == 'mysql')
{
   $result = mysql_query($sql);
}
else
{
   $result = pgsql_query($sql);
}

a tout bout de champ.

La solution serait donc de passer par une fonction, par exemple :

function exec_requete($sql)
{
   global $config_sgbd;

   if ($config_sgbd == 'mysql')
   {
      $result = mysql_query($sql);
   }
   else
   {
      $result = pgsql_query($sql);
   }

   return ($result);
}

// Et donc
$result = exec_requete($sql)

C'est une solution, mais il y a mieux : faire une classe. Voilà un exemple :

class Database
{
   // Une propriété qui compte le nombre de requete effectuées
   public $total = 0;

   // Pour executer une requête
   public function query($sql)
   {
      // Appel la méthode _query() qui sera définie dans les classes filles
      $result = $this->_query($sql);

      // En cas d'erreur autant la loguer, ça peut servir pour le debug
      if (!$result)
      {
         log_erreur('Erreur SQL : ' . $sql);
         trigger_error('Une erreur a été rencontrée sur le site, désolé pour la gène ocasionée');
      }

      // +1 requête
      $this->total++;
   }
}

// Pour gérer MySQL
class Database_mysql extends Database
{
   public function _query($sql)
   {
      return (mysql_query($sql));
   }
}

// Pour gérer PostGreSQL
class Database_pgsql extends Database
{
   public function _query($sql)
   {
      return (pgsql_query($sql));
   }
}

ce qui donnera à l'utilisation :

if ($config_sgbd == 'mysql')
{
   $db = new Database_mysql();
}
else
{
   $db = new Database_pgsql();
}

$db->query('Ma requete SQL');

(...)

echo 'Page executée avec ' . $db->total . ' requetes';

Tu peux bien sur ajouter d'autres méthodes (fonctions en gros) à tes classes pour gérer le reste (mysql_fetch_row(), mysql_num_rows(), etc ...)

Les avantages :

• Tu utiliseras partout dans ton script ton objet $db donc au simple coup d'oeil, toi ou un autre développeur saura qu'il s'agit d'une manipulation de la base de donnée.
• Si demain tu dois aussi gérer Sql Server, il te sufira de créer une classe Database_sqlserver étendant Database
• La POO te permet une organisation très poussée du projet (une classe pour la base de donnée, pour le thème, pour le XML, pour les news de ton site, pour tes membres, etc ...)
• La POO donne accès à pas mal d'outils (interfaces, abstract, public / private / protected, héritage, surcharge, etc...)

Pour pousser un poil plus et résoudre définitivement la lourdeur du code

if ($config_sgbd == 'mysql')
{
   $db = new Database_mysql();
}
else
{
   $db = new Database_pgsql();
}

tu peux implémenter ce design pattern :

class Database
{
   // Une propriété qui compte le nombre de requete effectuées
   public $total = 0;

   public static function &factory()
   {
      global $config_sgbd;

      $class = 'Database_' . $config_sgbd;
      if (!class_exists($class))
      {
         trigger_error($config_sgbd . ' n\'est pas une SGBD supportée par le projet');
      }

      $obj =& new $class();
      return ($obj);
   }

   // Pour executer une requête
   public function query($sql)
   {
      // Appel la méthode _query() qui sera définie dans les classes filles
      $result = $this->_query($sql);

      // En cas d'erreur autant la loguer, ça peut servir pour le debug
      if (!$result)
      {
         log_erreur('Erreur SQL : ' . $sql);
         trigger_error('Une erreur a été rencontrée sur le site, désolé pour la gène ocasionée');
      }

      // +1 requête
      $this->total++;
   }
}


// et pour créer l'objet :
$db = Database::factory();

Bien sur ça reste complexe tout ça, c'est pour ça que je t'encourage à te mettre dans le code, ça t'aidera beaucoup à comprendre.

Sinon pour compléter l'explication de zeus sur le principe, c'est qu'un objet est donc le regrouppement dans une structure d'une part des données (les attributs), et d'autre part des processus qui traitent ces données (les méthodes). L'intérêt de ce regrouppement est que du coup, l'objet est indépendant de l'extérieur et les méthodes sont là pour s'assurer qu'à tout moment, les données restent intègres et qu'un code extérieur à l'objet (extérieur à la classe dans un code), ne peut pas corrompre ces données, et donc tout processus de modification des données doit passer par les méthodes défines par la classe.

Par exemple, si on prend une classe qui gère et calcule les représentations polaires et carthésiens d'un complexe (il n'est pas nécessaire de connaître les notions, c'est juste un exemple).
Dans les données, on va avoir :
- La représentation carthésienne : 2 nombres décimaux
- La représentation polaire : 2 nombres décimaux
Dans les méthodes, on va avoir :
- Les méthodes de conversion polaire=>carthésien et carthésien=>polaire
- Les méthodes d'insertion selon telle ou telle représentation, qui va ensuite faire appel à la conversion pour mettre à jour l'autre représentation
Imaginons que l'on modifie une des deux représentations sans mettre à jour l'autre, les données seront corrompues, puisque les 2 représentations ne représenteront pas le même nombre. Et c'est pour cela que les méthodes sont là, pour permettre, même lorsque les données de son objet sont reliées les unes aux autres, d'avoir à tout moment des données correctes.

J'espère que mon explication a été claire, et pas trop abstraite.

Merci à tous, c'est déjà un peu plus clair, je dis bien un peu ^^. Il y aurait-il un tutoriel que vous me conseilleriez plutôt qu'un autre pour me lancer sérieusement là-dedans ?

Newbinours

Il y a ça : http://www.phpdebutant.org/article42.php

Alors là je dis OUI pour l'exemple bête comme chou mais ô combien instructif
Pouvons-nous dire vulgairement que la POO est à PHP ce que les CSS sont à la mise en page ?
J'entends par là un gain de temps et une réutilisation grâce à un appel constant dans tout le site.
Si c'est bien ça, quand devons-nous (en l'occurence moi lol) vraiment songer à la POO car moi j'me "contente" (malgré moi à cause de mes moyens) des sessions et du passage de variable de page en page.

Est-ce une tare ? Moins bien ? Plus gourmand ?

En tout cas merci

Newbinours

Ton parrallèle entre POO et CSS est presque vrai ...

Disons que l'un des avantages de la POO est de centraliser les méthodes, mais ça va encore beaucoup plus loin.
Le fait de gérer des objet et non plus des traitements permets une portabilité et une évolutivité incroyable.

peut être mais alors pourquoi ne pas faire du J2EE au lieu de la limitation de php5 en poo, les struts et compagnie mette a genoux php. L'interêt va à des projet conséquent.
Mais même un site e-commerce en poo sa n'à pas de sens...
En langage structuré une bibliothèque de fonction bien conçu vaut largement le coup et j'ajouterai qu'il n'y a quasiment pas de livre pour apprendre le php avec la poo, na

Sans doute parce que php n'est pas java... que si tout le monde à le framework struts en tête, il n'en reste pas moins une énorme usine à gaz qui a autant de contraintes que d'avantages et qui n'est probablement réellement vallable que pour 10 à 15% des projets web.

Un site e-commerce en poo a autant de sens que n'importe quel autre site dans n'importe quel autre langage. L'objet permet de réutiliser des classes, d'hériter des propriétés, de disposer de plusieurs instance d'un produit et sera sans doute bien plus clair et facile à manipuler qu'un énorme tableau en session qui fera office de panier... Bien sur qu'une bibliothèque de fonction peut facilement remplacer toutes les méthodes, à toi de voir ensuite si tu veux te galérer à redéclarer et réinitialiser tous les attributs à chaque et à les multiplier par autant d'instance que nécessaire ou si tu ne préfères pas tout avoir sous la main et ne pas te poser de question

Quant à un livre, je dirais qu'il n'y a pas besoin de langage pour apprendre la poo. Si tu sais manipuler des objets tu sauras en faire en java, en php, en asp, ... même en js (!), suffit juste de t'adapter à la syntaxe, et la doc (voire juste un chapitre si tu tiens à un livre) pour ça est largement suffisante