[POO] Avantages de la programmation orientée objet en PHP 5 [Débat]

[Yogui]

Envoyé par Kalishah

- Peut-on parfaitement dissocier le php (logique) du html (vue) ?
- Peut-on créer simplement des contrôles personnalisés réutilisables à souhait, un système de menu par exemple ?
- Quels outils utilser pour faire du php "objet" ?
- Y a t'il des bibliothèques de classes disponibles et prêtes à l'emploi qui évitent d'avoir à réinventer la roue ?

PHP permet en effet de dissocier la logique de la vue, mais il y a toujours un point de fusion... C'est le principe des templates :
Sondage : [Templates] Quel système utilisez-vous ? Pourquoi ?
http://php.developpez.com/cours/#bibliotheques-gabarits

Le modèle objet de PHP 5 est devenu très proche de ce que l'on peut faire dans les langages objet plus anciens : http://php.developpez.com/cours/#langage-poo

Les outils sont bien évidemment un très bon EDI :
Quel est l'éditeur que vous recommandez pour PHP ?
http://php.developpez.com/cours/#outils-edi

Les bibliothèques dont tu parles sont en fait des frameworks :
http://zend-framework.developpez.com/cours/
Sondage : Quel framework PHP utilisez-vous et pourquoi ?

[Galak`]

Ce que je vais dire est peut-être aussi inintéressant qu'inexact, mais voila en gros les avantages que je vois tous les jours en utilisant la POO en PHP (et je ne parle que des avantages évidents qu'on voit même sur de petits projets).

J'ai remplacé depuis longtemps les fonctions éparpillées dans divers fichiers (voire regroupées dans un gros fichier...) par des classes abstraites, comme les premiers exemples du topic, qui sont en fait des librairies de fonctions. Perso, je regroupe ces classes dans un dossier "lib" en donnant aux fichiers un nom de la forme "nom_classe.lib.php".
Par exemple :
- str.lib.php regroupe les fonctions sur les chaines de caractères
- url.lib.php regroupe les fonctions de gestion des url
- img.lib.php les fonctions de gestion des images
- file.lib.php les fonctions de gestion des fichiers
- form.lib.php les fonctions de génération de formulaires
- pas mal d'autres...
- et enfin tool.lib.php qui regroupe les inclassables

On pourrait faire de même en procédural, mais l'avantage de ces classes est d'avoir des noms de méthodes simples. Voir un img::exists() et un file::exists() me parait beaucoup plus clair et propre qu'un imgExists() et un fileExists(). On voit tout de suite dans le source de quelle librairie vient la méthode. On sait que url::str2url() vient de la librairie "url", alors qu'on ne sait pas forcément si str2url() vient de la librairie "url" ou de la librairie "str". Et c'est encore plus évident avec les noms de méthodes plus complexes.


Ensuite, il y a les "vrai" classes avec déclaration d'objets. Je les place dans un dossier "classes" avec un nom de fichier de la forme "nom_classe.class.php".
Par exemple :
- mysql.class.php : classe d'abstraction MySQL
- bench.class.php : classe de bench
- user.class.php : classe de gestion de l'utilisateur (login, restauration de session...)
- theme.class.php : mon petit moteur de templates
- client.class.php : classe de gestion du client (détection navigateur, os, robots, ip, stats...)
- pagination.class.php : classe de génération de la pagination
- quelques autres...

L'avantage ici aussi est d'avoir un objet unique qu'on traine tout au long de nos scripts pour accéder à toutes les méthodes, mais aussi à toutes les propriétés pour chaque domaine.
Par exemple, l'objet $user est utilisé pour se loguer ou restaurer la session de l'utilisateur courant, et une fois fait, tout au long des scripts je peux avoir par son intermédiaire son niveau d'accès, son nom et toutes les propriétés du genre.
Pour avoir la même chose en procédural, il faut avoir pas mal de fonctions, qui stockent les propriétés par exemple dans des variables globales, qu'il faut déclarer globales dans toutes les fonctions les utilisant. C'est beaucoup moins propre et ca devient bien vite fouilli, aussi bien au niveau des méthodes que des propriétés. C'est quand même plus clair dans le code d'avoir toujours un "$user->" lorqu'on fait un action sur l'utilisateur ou récupère une de ses propriétés que d'avoir des noms de fonctions divers et des noms de variables globales.
C'est même une évidence quand on commence à avoir plusieurs objets dans son appli. Perso, j'ai $user pour gérer l'utilisateur, $client pour tout ce qui concerne son environnement (navigateur, os), $sql pour toute la BDD...
Ca permet aussi une réutilisabilité optimale. Je traine dans tous mes projets la plupart de ces classes sans même les retoucher.

Bien sur certaines classes ne sont pas faites pour avoir un seul objet unique qu'on traine tout le long. Avec la classe pagination, je crée un objet auquel je passe le numéro de l'élément courant, le nombre d'éléments, le nombre d'éléments par page, l'url de base du lien et quelques autres infos, et à partir de ça je peux faire ce que je veux niveau pagination, afficher la page courante quelque part, le menu pour changer de page ailleurs, chaque fois en faisant appel à une des méthodes de cette classe à partir de l'objet déclaré avant, méthodes qui se servent des propriétés stockées une fois dans l'objet pour générer chaque élément qu'on demande, sans devoir encore et toujours repasser les valeurs pour chaque élément.
En plus de simplifier l'utilisation de ces fonctions, ça facilite et clarifie aussi fortement leur codage, vu qu'on à moins de paramètres à gérer pour chacune d'elle. On passe les paramètres au constructeur qui les traite et les stocke, et on les utilise directement dans chaque méthode, plutôt que récupérer et traiter chaque paramètre dans chaque fonction.


En gros, on peut vaguement faire en procédural tout ce qu'on fait en POO, mais alors voila le bordel et le coté "sale" de la programmation. Et psychologiquement, c'est quand même beaucoup (mais alors beaucoup) plus agréable de coder avec des classes et librairies de fonctions bien définies, on est à l'aise, on a l'impression de maitriser.
Avec des fonctions éparpillées, on passe son temps à chercher comment nommer les fonctions, comment nommer les variables globales, où placer les fonctions, à repasser les mêmes paramètres à plusieurs fonctions, et si on se laisse aller à faire des nommages et des placements hasardeux, on passe beaucoup de temps à s'y retrouver, à chercher ses fonctions, à chercher quelle fonction fait telle action, à chercher quelle variable contient telle info. On a à l'inverse l'impression d'être dépassé par son projet.

Bref, pas évident de faire comprendre à quelqu'un qui n'a jamais fait de POO à quel point c'est différent et avantageux, même dans une utilisation basique comme celle que je viens d'essayer de montrer.

[zulot]

merci pour ces quelques exemples, qui m'ont beaucoup aidé pour le php.
en meme temps j'ai deja fait de l'objet, mais je ne voyais juste pas l'avantage en php, ne comprenant pas vraiment comment fonctionnait l'objet dans la compilation.

Je me suis bien rensegné et j'avoue que c'est pas mal quand meme.
Mais les habitudes sont longues a changée mais je m'y mets.

[zulot]

Envoyé par Galak`

- img.lib.php les fonctions de gestion des images

Pourrais tu me donner un exemple de img lig et comment on s'en sert car la je suis un peu dans le flou

[Galak`]

Envoyé par zulot

Pourrais tu me donner un exemple de img lig et comment on s'en sert car la je suis un peu dans le flou

C'est juste ma librairie de fonctions de gestion des images, des fonctions comme exists qui vérifie si un fichier image existe, une fonction retournant le chemin d'une image à utiliser partout, des fonctions pour générer ou redimensionner des images...

[afrodje]

Commençant à developper l'objet (en PHP), je me posai une question, certe stupide, mais impossible à me répondre seul.

J'ai découvert l'objet, et me suis dit " C'est pareil qu'un fonction en faite !".

Prenons le code précedent en objet

Code :

1
2
3
4
5
6
7
8
9
10
11
abstract class Calendar
{
   public static function frenchDate($date)
   {
         $temp = explode("-",$date);
         $res = $temp[2]."/".$temp[1]."/".$temp[0];
         return($res);
   }
}
 
echo Calendar::frenchDate($date);

et voici en fonction

Code :

1
2
3
4
5
6
7
8
9
10
fonction Calendar($date)
{
 
         $temp = explode("-",$date);
         $res = $temp[2]."/".$temp[1]."/".$temp[0];
         return($res);
}
 
 
echo Calendar($date);

Alors pourquoi l'objet est il si puissant?
(je sais j'en suis qu'au début, il doit avoir d'autre possibilité mais la question m'a traversé l'esprit, je déprime, je dors plus )

[zulot]

Alors principal raison qui pour moi m'a fait passer a l'objet avec de gros projet c'est celle ci (cité plus haut)

On pourrait faire de même en procédural, mais l'avantage de ces classes est d'avoir des noms de méthodes simples. Voir un img::exists() et un file::exists() me parait beaucoup plus clair et propre qu'un imgExists() et un fileExists(). On voit tout de suite dans le source de quelle librairie vient la méthode. On sait que url::str2url() vient de la librairie "url", alors qu'on ne sait pas forcément si str2url() vient de la librairie "url" ou de la librairie "str". Et c'est encore plus évident avec les noms de méthodes plus complexes.

En gros tu sais dans quel fichier est ta fonction.

[koopajah]

oui et non. La tu te penches sur un point précis de l'objet que sont les classes statiques, qui permettent donc de regrouper un ensemble de fonctions dans une classe donnée pour mieux les trier/classer/organiser/distribuer etc.

Mais ca reste une petite partie de l'objet tout de meme, a coté de l'héritage, des surcharge, des variables privées/protégées/publiques etc.

[afrodje]

OK

Les fonctions sont bien structuré mais dans un fichier quelconque.
Alors que les classes sont bien structuré aussi, et bien rangé dans le fichier approorié (en gros)

J'ai bien compris professeur?

[berceker united]

Envoyé par afrodje

Commençant à developper l'objet (en PHP), je me posai une question, certe stupide, mais impossible à me répondre seul.

J'ai découvert l'objet, et me suis dit " C'est pareil qu'un fonction en faite !".

Prenons le code précedent en objet

Code :

et voici en fonction

Code :

Alors pourquoi l'objet est il si puissant?
(je sais j'en suis qu'au début, il doit avoir d'autre possibilité mais la question m'a traversé l'esprit, je déprime, je dors plus )

Calendar peut faire partie d'un groupe de fonctionnalité traitant des dates. Si tu n'utilises que ça pour traiter des dates alors il y a pas lieu d'utiliser une classe.
T'es toi même un objet et ta mère ta instancier à ta naissance ! Tu es un ensemble de fonctionnalité .
Retourne le problème dans l'autre sens. La notion objet est née de ce qui existe autour de nous.
Comme je l'ai déjà dit : L'objet est une vue d'esprit qui s'applique à la programmation.

[mathieugamin]

Une application web "objet" nécessite d'étre intégralement conçue avant d'être écrite, c'est encore plus vrai que dans le cas d'un langage procédural.

D'expérience, c'est plus qu'un bon conseil.

Pour passer du coq à l'âne, les grands avantages que je trouve à la POO appliquée à un site Internet, sont :
- la clarté du code,
- la sécurité,
- la centralisation des fonctions,
- la possibilité de modifier facilement (ajout suppression) les fonctionnalités,
- la maintenance ainsi plus aisée...

En fait j'en trouve plein....
Plus je développe et plus je trouve la POO intéressante et adaptée.

Comme le Bersecker United, il faut avoir le nez dedans...

[mathieu]

Les avantages de la POO sont les mêmes que se soit en PHP ou en Java donc cette discussion n'apporte peut-être pas grand chose pour la POO en générale.
Est ce que je me trompe ?

[zulot]

Envoyé par mathieu

Les avantages de la POO sont les mêmes que se soit en PHP ou en Java donc cette discussion n'apporte peut-être pas grand chose pour la POO en générale.
Est ce que je me trompe ?

Effectivement la base etant php5 POO Vs php4

[mathieugamin]

Envoyé par mathieu

Les avantages de la POO sont les mêmes que se soit en PHP ou en Java donc cette discussion n'apporte peut-être pas grand chose pour la POO en générale.
Est ce que je me trompe ?

Non, tu as raison

Pour recentrer : les avantages en PHP5 les plus notables à mes yeux :
- la copie et la référence (PHP5 fait par défaut un passage par référence d'un objet alors que PHP4 en faisait une copie)
- le déréférencement des méthodes (on n'est plus obligé de sauvegarder le résultat d'une méthode dans une variable lorsqu'elle renvoie un objet)

C'est ce que je trouve le plus pratique dans l'utilisation que j'en fais...

[binouzzz19]

Personnellement, je n'utilise pas PHP5 pour le moment mais je pense l'intégrer bientôt dans mes projets.

Cependant, il me semble qu'il y a un autre avantage à PHP5, (je ne sais pas si c'était possible dans les versions antérieures) il s'agit des smarty, ces fameux tamplates qui permettent de séparer le php de l'HTML je dirais. En gros c'est une sorte de MVC chez Java.

N'est-ce pas un autre avantage ? Est-ce que je dis une bétise ?

[Yogui]

Smarty n'est pas codé en PHP5 mais dans des versions antérieures, cf. mes tutos et en particulier le comparatif des moteurs de templates pour davantage de détails.

[supergogol]

bonjour,

vous avancer beaucoup comme argument le fait que ça soit mieux organisé, qu'on retrouve plus facilement les choses...même si c'est tout à fait vrai, ce n'est pas la nature première de la POO.
Le but est de pouvoir encapsuler (cacher) les différents comportements et d'exposer au reste du programme un seul jeu de méthode. Et c'est en ça que la maintenance est simplifié: on peut modifier un algorithme entier, sans avoir a modifié le code qu'il l'utilise! Suivant la même idée, il est très facile d'étendre un objet avec l'héritage ou le pattern décorateur. L'application de ces derniers rend votre application plus compréhensible et plus sûr en utilisant des techniques éprouvées.

A mes yeux, la POO est en plus une façon de faire bien plus naturelle que le procédurale. Un animal, par exemple, n'est pas un ensemble d'éléments éparpillés, c'est un "objet" avec des comportements!

ps: smarty n'est en rien du MVC. C'est simplement un moteur de template. Il est par contre très simple de l'intégrer dans une telle approche.

[zulot]

Envoyé par supergogol

bonjour,

vous avancer beaucoup comme argument le fait que ça soit mieux organisé, qu'on retrouve plus facilement les choses...même si c'est tout à fait vrai, ce n'est pas la nature première de la POO.
Le but est de pouvoir encapsuler (cacher) les différents comportements et d'exposer au reste du programme un seul jeu de méthode. Et c'est en ça que la maintenance est simplifié: on peut modifier un algorithme entier, sans avoir a modifié le code qu'il l'utilise! Suivant la même idée, il est très facile d'étendre un objet avec l'héritage ou le pattern décorateur. L'application de ces derniers rend votre application plus compréhensible et plus sûr en utilisant des techniques éprouvées.

A mes yeux, la POO est en plus une façon de faire bien plus naturelle que le procédurale. Un animal, par exemple, n'est pas un ensemble d'éléments éparpillés, c'est un "objet" avec des comportements!

ps: smarty n'est en rien du MVC. C'est simplement un moteur de template. Il est par contre très simple de l'intégrer dans une telle approche.

Tu derive l'amis cf :

Effectivement la base etant php5 POO Vs php4

On ne parle pas de la POO en général cf aussi 4-5 poste plus haut

[berceker united]

Envoyé par zulot

Tu derive l'amis cf :



On ne parle pas de la POO en général cf aussi 4-5 poste plus haut

De toute façon ça fait longtemps que sa dérive.

[jpsoft]

Bon je vais me faire lyncher mais c'est pas grave.
Je suis absolument contre la systématisation de la POO.
Le plus dur est de savoir à partir de quel moment il faut en faire et réciproquement quand il faut arrêter le délire.
Assez de lire que le code est simplifié, plus facile à lire.
Au niveau des compétences nécessaires, le niveau pour faire de la POO est nettement supérieur au niveau nécessaire en procédural.
J'ai exemple d'un grand projet entièrement POO qui à du être réaménager pour une grande partie en procédural pour tenir la charge.
La différence entre un singleton et une liste d'Apis et de variables n'est que philosophique, la rapidité d'exécution,elle, ne l'est pas.
Cdt