Quand - exactement - utilise-t'on la POO ?

La programmation non-objet est devenue une hérésie en informatique depuis longtemps.
Sauf quand on fait un script batch par exemple, mais ça n'est pas une application (un site web, c'est une application).

Pour moi je vois ça comme plus de "propreté".
Si on a un fichier pour le header, un fichier pour le footer, et un fichier pour le contenu (un par page), on fait un include header, etc. Mais les variables du fichier dans le header sont propagées du coup aux autres scripts inclus. Il peut y avoir des variables écrasées par d'autres, où initialisées à ailleurs...
Alors que si en plus de faire l'include, on doit faire un "header = new Header()" puis "header->display()" alors tout est hermétique, on agit sur le header proprement, comme "header->title = 'home'" sans avoir un $title qui peut être utilisé dans le content, le footer, etc.

Ca va de paire aussi avec le MVC.

Bref : si c'est un code qui a des chances d'être vu ou utilisé par d'autres, si on ne veut pas avoir honte, il faut faire de la POO un minimum (rien ne doit se trouver en dehors d'une classe).
Côté performances ça n'apporte rien par contre.
C'est pour mieux organiser et réutiliser les classes dans un autre projet, quand tu en feras d'autres, c'est plus simple de reprendre des éléments, car chaque classe est bien indépendante et peut se retrouver dans n'importe quel autre projet.
C'est comme ça que je vois les choses... après on fait comme on veut, il peut y avoir des bons programmeurs sans utiliser de POO et des mauvais qui utilisent la POO...

 

+1

Les bons programmeurs ont toujours écrit du code lisible et les mauvais écriront toujours du code pourri, mais la POO est à la mode. Pour les petits projets, elle ne fait qu'alourdir les choses.

Jean-Luc

 

WP n'est pas fort POO, il y a quelques classes mais c'est beaucoup de méthodes globales / programmation spaghetti.

NB: il y a de bons tutos noob friendly chez Grafikart: http://www.grafikart.fr/formations/programmation-objet-php

 

Perso j'ai un avis plus nuancé que Rick38, le full POO je ne trouve pas ça géant (faut voir au cas par cas). En revanche ou je semble rejoindre tout le monde c'est dans la notion de "programmation structurée". Je ne sais pas si le terme est encore utilisé mais quelques soit le code (Objet ou procédural), il conviens de d'adopter une grosse rigueur d'écriture pour être compréhensible.

Le côté POO me fait toutefois un peu sourire car je ne compte plus les cas ou on bazarde l'ancien sans s'en soucier (sur le web) ...

Le truc qui dicte mes choix c'est la conso machine. Un modèle full objet peut vite devenir lourd si tu brasse énormément d'objets ... Donc écrire une classe oui mais pas forcement pour tout. J'ai vécu des exemple ou j'ai du sortir des objets du code pour revenir a un bête système de requête / boucle / affichage car l'instanciation de multiples objets était une vrai galère machine.

Le secret de la POO semble donc se cacher dans une bonne vision du modèle globale a produire et une étude réfléchie des ressources qu'il va solliciter.

 

Bonjour la programmation poo va de pair avec la méthode mvc.
Programmer ainsi, c'est t'aider à structurer ton travail. Il n'y a pas de petit ou gros projets. Il y a juste une méthodologie. Et avec le temps et la pratique, tu te rendras compte que tes gros projets sont rapidement fait !
Gain de temps énorme en maintenance et en évolution.
Même s'il s'agit d'un petit projet, c'est formateur.
Le code à l'arrache ne t'apporte rien.
De plus, grâce à des classes comme PDO, elle te permettra d'accéder et sécurisé tes requêtes sql.
Bref.... C'est un non sens amha !

 

On est d'accord, mais celui qui fait du code à l'arrache en procédural en fait tout autant en POO.

Ecrire du code de qualité (lisible, structuré, efficace), c'est une question de compétence et de discipline. Après qu'on fasse du procédural ou de la POO, c'est le choix d'un environnement de travail plus ou moins bien adapté au problème à traiter.

Jean-Luc