POO ou pas POO ?

WRInaute discret
Bonjour,
Je suis en train de commencer un nouveau site et je me demande s'il vaut mieux le développer PHP Orienté Objet ou en procédural.
En fait c'est un site ou il n'y aura qu'un développeur (moi) et il sera pas très complexe au niveau prog. Mais s'il est un peu fréquenté (ce que j'espère comme tout créateur de site :wink: ) il consommera un pas mal de ressources d'où cette question sur l'optimisation de mon code. :?:
Merci d'avance pour vos conseils. :D
 
Nouveau WRInaute
shelcko a dit:
Bonjour,
Je suis en train de commencer un nouveau site et je me demande s'il vaut mieux le développer PHP Orienté Objet ou en procédural.
En fait c'est un site ou il n'y aura qu'un développeur (moi) et il sera pas très complexe au niveau prog. Mais s'il est un peu fréquenté (ce que j'espère comme tout créateur de site :wink: ) il consommera un pas mal de ressources d'où cette question sur l'optimisation de mon code. :?:
Merci d'avance pour vos conseils. :D

Ca dépend vraiment du contenu de ton site web.

Il n'est pas intéressant de programmer en POO pour programmer en POO, il faut qu'il y ai un but, une nécessité de représenter les objets en tant que tels.

Par exemple, une utilisation de la BDD accouplée à une classe POO peut-être intéressant. Pareil pour un site ecommerce par exemple, avec des classes produit, catégorie, panier...

Bref il n'y a pas de réponse toute faite, elle dépend de ce que tu vas créer.
 
WRInaute discret
En fait je cherche encore des fois l'intérêt de la POO car je développes depuis plusieurs années en PHP de la même façon avec mes petites fonctions que je ressors quand j'ai besoin.
Il est vrai que sur mon dernier projet je me suis appliqué à travailler en POO est c'est quand même vraiment plus organisé et plus propre.
Mais ce nouveau site va être une sorte de gros formulaire plus ou moins complexe donc s'il fonctionne il y a aura beaucoup de requêtes (peu complexes) mais sur une BDD de plusieurs milliers de lignes (à moins que je trouve un moyen de l'optimiser encore plus).
Donc je me dis que faire de la POO c'est sympa quand tu bosses sur un gros projet en groupe ou pour utiliser des classes sympas (fpdf ou autre) mais si c'est juste pour avoir un code "plus propre" je voulais savoir si ça valait le coup de perdre un peu en performances et combien je risque de perdre.(car c'est vrai que si on pense que le site va évoluer la POO est quand même pratique par rapport au procédural).
Donc en gros j'ai à peu près autant d'arguments pour que contre et je ne sais pas vraiment combien je peu perdre en perf (et j'ai pas vraiment envie de développer mon site 2 fois pour comparer :wink: )
 
WRInaute accro
Evidemment POO. Peut-être un peu plus dur à concevoir pour bien séparer le tout en différentes classes et différentes fonctions réutilisables, mais après, que du bonheur pour retrouver ou modifier un truc ;)
 
WRInaute discret
YoyoS a dit:
Evidemment POO. Peut-être un peu plus dur à concevoir pour bien séparer le tout en différentes classes et différentes fonctions réutilisables, mais après, que du bonheur pour retrouver ou modifier un truc ;)
En fait on s'éloigne du sujet de départ en fait je voulais avoir une idée de la perte de perf engendrée par la POO par rapport à la prog procédurale. Je crois que je vais faire des test pour me rendre compte par moi même.
Merci quand même.
 
WRInaute impliqué
POO, c'est obligatoire si on a un tant soi peut creusé la conception du site.

Maintenant si on fait just 3 lignes de PHP pour remonter un champ SQL, l'intérêt est minime effectivement
 
WRInaute occasionnel
POO !!!

Sans hesitation ! Franchement meme pour des petits projets tu y gagne vraiment en maintenance.

Pour ce qui est des perf, si tu code correctement, il n'y aura pas de difference. Ca permet meme de faire un code plus propre et au final ca peut meme permettre d'optimise le code.
 
WRInaute passionné
En php, je ne m'y suis jamais fait ... se casser la tête quand on est pas un pro de la POO... suis trop fainéant pour m'y mettre lol.
Une bonne utilisation des fonctions est suffisant pour la plupart des sites et permet tout autant d'y gagner dans la maintenance.

Le seul avantage de la POO, c'est comme il a été dit, la compréhension "rapide" du développement quand on est plusieurs à être dessus.
 
Nouveau WRInaute
Hello,

POO à tout les coups !
Meme si PHP n'est pas un vrai language OO (encore beaucoup de lacunes comparé à JAVA RoR C++ etc.)
Utilisation de librairies au maximum (les plus populaires et plus efficaces) par ex : ADODB pour l'abstraction à la DB.
Encore mieux, un framework à partir du moment où le site est un peu plus conséquent. => Symfony
Et pour aller plus loin : prototype ou jquery pour ce qui est ajax / javascript

J'oubliais, il y a aussi les librairies PEAR ...

Pour ce qui est de la performance, tout dépend de la qualité du code. (php / mysql / js / .... )
Si tu utilises des lib / framework, c'est vrai qu'il y aura certainement une quantité de fonctions dont tu n'auras pas besoin (et peut être un peu plus lent à l'exécution) mais il ne faut pas oublier que des gens améliorent les lib / framework tout les jours ... et par exemple pour un module de sécurité (login / pass), prends une librairies qui sera alors bien plus sécurisée que les quelques lignes de code faites maison en quelques heures.

Manu
 
WRInaute impliqué
ah bah tiens je vais tenir des propos inverses à tout ce qui a été dit :D avec des arguments qui sont que l'objet en php à un cout moins en php5 mais y a pas photo et l'autre argument que la poo en php c'est de la blague et je vais par là même ressortir mon exemple :

Code:
 class nomDeMaClasse {
    private $propriete;
    public function __construct() {
	$this->toto = 12;  
    } 
    public function __destruct() {
    }
}
  $nameDeMaClasse = new nomDeMaClasse();
   echo $nameDeMaClasse->toto; //affiche 12 :-(

c'est très moche tout de même :)
 
Nouveau WRInaute
?

Désolé mais je ne vois pas en quoi l'exemple que tu donnes démontre que la POO en PHP c'est de la blague ... :?
Effectivement cela affichera 12 mais si tu es habitué à d'autres language OO plus strictes, tu devrais définir toto avant ton constructeur en private ou protected.

Par contre, je trouve dommage d'appeler un constructeur __construct (PHP5) et non pas avec le nom de la classe (PHP4 et d'autres languages OO)

pas de surcharge de méthodes, pas de polymorphisme sont par contre pour moi des lacunes du language.
Et pas de typage fort, mais ça, ça se discute ....
 
WRInaute impliqué
ManuxBE a dit:
?
Effectivement cela affichera 12 mais si tu es habitué à d'autres language OO plus strictes, tu devrais définir toto avant ton constructeur en private ou protected.

c'est bien ce que je reproche à la POO de php, à quoi cela sert-il proposer des mots clefs comme var, protected, public ou encore private, si tu peux définir des attributs à la volée et qui plus est public au niveau de la sécurité...
 
WRInaute accro
Mdr. En effet ta classe est très moche. Fais en une utile et 100x plus grosse, on verra après :mrgreen:

T'aurais déjà pu optimiser ta petite classe de merde ;)
Code:
    public function affichetest() {
          echo $this->toto;
    }

   // T'as juste à faire
   $objet->affichetest();

Très utile quand tu fais du debuggage, en un appel tu peux afficher 10000lignes. Ca sert à encapsuler alors je vois mal faire pour chaque ligne echo $objet->variable ;)
 
WRInaute accro
shelcko a dit:
En fait c'est un site ou il n'y aura qu'un développeur (moi)
Donc, tu mets de l'anti-poo, comme ça, t'es pas emmerdé.

shelcko a dit:
et il sera pas très complexe au niveau prog.
C'est toujours plus simple sans poo.

shelcko a dit:
...il consommera un pas mal de ressources d'où cette question sur l'optimisation de mon code. :
Si tu codes avec un poo pourri, c'est mort coté poower.

De toute façon, si tu connais pas le poo, évite le bug et code comme tu le sents.

:mrgreen:
Me suis bien marré.
 
Nouveau WRInaute
Rod la Kox a dit:
shelcko a dit:
et il sera pas très complexe au niveau prog.
C'est toujours plus simple sans poo.

Peut être pour le développement (quoi que non) mais pour l'évolutivité et la maintenance ... merci ...

Exemple bête et méchant : un produit est référencé sous la forme 1234, si demain on change le système de numérotation et que chaque produit est référencé sous la forme : 1234-23 où 23 est la catégorie du produit, il faut reprendre tout le code et chercher ou on affiche le code produit.

Avec la POO, normalement il n'y a qu'un seul endroit pour avoir le code produit : dans la class produit

Avant :
Code:
public function getProductId() {
       return $this->iProductId;
}

Après :
Code:
public function getProductId() {
      return $this->iProductId."-".$this->getProductCategoryId();
}
A peu de choses près tout est changé en quelques minutes.

Après on peu débattre si PHP est vraiment OO ou pas ... mais c'est un HS.
En tout cas, par expérience sur de gros projets PHP (seul ou en équipe) c'est bien plus utile, direct et clair.
 
WRInaute impliqué
YoyoS avec tout l'estime que je porte à tes réponses sur ce forum, je pense que là, tu n'as pas voulu saisir ou fait semblant de ne pas comprendre ce que je voulais dire, enfin c pas grave, la moralité c'est qu'avec un langage comme php le gars qui fait sciemment ou pas de la merde c pas l'objet de php5 qui va l'en empêcher :lol:
 
WRInaute accro
Je te chariais hein :D C'est qu'il ne vaut mieux pas donner un exemple de poo sans rentrer dedans totalement sinon ça sert à rien :D La POO c'est une analyse complète d'un projet en orienté Objet et pas seulement une petite classe avec une fonction ;)

Tiens par exemple j'ai du installer un script d'administration pour un serveur de jeu trackmania. Aseco est un script en php5 totalement orienté objet. C'est déjà difficile de s'y retrouver dedans alors que c'est assez bien structuré pourtant. Imagine maintenant avec de simples fonctions !

C'est sur que pour faire un echo $objet->toto est rien d'autre, oui ça sert à rien la poo, tout comme de faire une fonction alors ;) En fait, à partir du moment ou tu fais des fonctions et que tu peux en ressortir des groupes de fonctions de même type ou qui travaillent dans un même milieu, tu devrais passer à la POO et faire une analyse complète.
 
WRInaute impliqué
julienr a dit:
c'est bien ce que je reproche à la POO de php, à quoi cela sert-il proposer des mots clefs comme var, protected, public ou encore private, si tu peux définir des attributs à la volée et qui plus est public au niveau de la sécurité...

si tu en remets une couche sur le echo $objet->toto je me demande si tu as bien lu la réponse ci-dessus...
 
WRInaute accro
Non je pensais pas en remettre une couche. Pour moi faut faire de la poo correctement, sinon s'en est pas. Php5 est trop laxiste pour le moment de ce côté là. De toute façon la question de départ n'était pas de faire un bon ou mauvais POO :D

POO oui, c'est tout :mrgreen:
 
WRInaute accro
J'ai pas envie de me la jouer "normand", mais... chacun son truc, non ?
Je ne suis pas OO non plus (par flemme: pas envie de revoir toute ma logique... j'ai tout en tête), mais je travaille avec un certain nombre de fonctions relativement récurrentes dans mes différents projets, et ça me suffit à sortir quelquechose de propre.
 
WRInaute passionné
Robinson a dit:
Le seul avantage de la POO, c'est comme il a été dit, la compréhension "rapide" du développement quand on est plusieurs à être dessus.

Pas uniquement.
Cela oblige à réfléchir un peu plus à ce qu'on fait et mieux organiser la structure de son code, à faire un truc plus lisible, plus logique, beaucoup plus facile à maintenir.
Je ne parle même pas de la facilité à revenir sur son propre code lorsqu'on l'a laissé de coté un certain temps.
 
WRInaute accro
ManuxBE a dit:
pas de surcharge de méthodes, pas de polymorphisme sont par contre pour moi des lacunes du langage.
Et pas de typage fort, mais ça, ça se discute ....
+1
ManuxBE a dit:
Exemple bête et méchant : un produit est référencé sous la forme 1234, si demain on change le système de numérotation et que chaque produit est référencé sous la forme : 1234-23 où 23 est la catégorie du produit, il faut reprendre tout le code et chercher ou on affiche le code produit.
avec du procédural, aucun problème là dessus.

J'ai du mal à comprendre en quoi le fait de programmer en POO fait faire du meilleur code. Un mauvais développeur fera du mauvais code, que ce soit en poo ou en procédural.
La réutilisabilité peut aussi bien se faire avec du procédural.
Quand je vois un certain nombre de sources en poo, je suis quand même effaré par le codage, donc non, la poo (surtout en php) ne fait pas obligatoirement faire du bon codage
 
WRInaute impliqué
non la POO c'est élégant spirituellement, mais ce n'est qu'une implémentation comme une autre d'une analyse par entitée
 
WRInaute accro
Et puis c'est vrai qu'en php il n'existe pas vraiment d'outils aussi poussé que Netbeans ou Visual Studio. Ca manque. Après on sait plus faire sans poo :D

Il y a zend studio, mais je veux encore plus poussé :mrgreen:
 
WRInaute accro
le problème de la poo, c'est la factorisation à outrance juste histoire de faire des classes et au lieu de faire une fonction ou une procédure qui tiendrait en 3 lignes et qui n'a pas besoin d'être réutilisée dans le code, on va implémenter 2 classes qui, au total, vont faire 20 lignes :roll: En plus, on va se retrouver avec plein de méthodes sans intérêt dans la quasi totalité des cas, mais on sera content, car au cas où on en aurait besoin, cette méthode existera :D
 
WRInaute accro
Le problème de la poo ? Moi je vois ça comme une bénédiction oui ce que tu viens de dire. si pour quelques lignes de plus tu peux relire ton code 2ans après et comprendre directement sans commentaires, je prends direct -_- Evidemment c'est plus chiant à faire au début, c'est pour ça que j'aimerais des outils plus poussés comme netbeans et visual studio qui te créent les classes tout seul.
 
WRInaute accro
Déjà testé, ça foire légèrement :/ C'est pas pour rien qu'il sort une update tous les 2 jours ;). Puis j'aimerais un outil complet ou tu peux directement travailler sur des pages hébergées sur le net. Je testerais bien la 2.6 pour voir si il y a eu bcp de changement ou pas :) Merci de me le rappeler !

EDIT: A ben tiens, une update hier mdr.
 
WRInaute accro
YoyoS a dit:
Le problème de la poo ? Moi je vois ça comme une bénédiction oui ce que tu viens de dire. si pour quelques lignes de plus tu peux relire ton code 2ans après et comprendre directement sans commentaires, je prends direct
Si Eclipse lors de la création d'une classe te propose d'ajouter des commentaires ainsi que les commentaires des paramètres, c'est bien que cela a un intérêt. Un code non commenté pour arriver à t'y retrouver franchement :?
YoyoS a dit:
Evidemment c'est plus chiant à faire au début, c'est pour ça que j'aimerais des outils plus poussés comme netbeans et visual studio qui te créent les classes tout seul.
création de classes semi-automatiques, cela ne veut pas dire obligatoirement bonnes classes.
C'est comme de croire que parce qu'une page web est valide xhtml alors c'est qu'on l'a bien codée
 
WRInaute accro
YoyoS a dit:
Mais calme toi, je parle pas de ceux qui codent mal, c'est pas le sujet lol
Je ne suis pas énervé. Selon les cas, je développe en objet ou en procédural. Cela dépend des besoins. Ca ne sert à rien de faire de l'objet juste pour se dire "ouai, trop cool, j'ai développé un site web 2.0 en POO" :lol:
Après, faire croire aux webmasters qu'ils vont être obligés de bien développer parce qu'ils le font en POO, non. Et donc s'ils ne développent pas en POO c'est qu'ils ne savent pas développer...
Dans quel cas est-on "obligé" de développer en objet ? quand on veut envoyer un résultat d'une fonction non linéaire. En entrée, ça n'est pas génant, il suffit d'avoir plusieurs variables, mais en sortie, en dehors de la possibilité de renvoyer un tableau, pas d'autre possibilité (sauf si on utilise des variables globales, mais bon :roll: )

Et puis, quand on a goûté la POO avec des vrais langages structurés et fortement typés (java, ...) on voit quand même beaucoup de lacunes à la POO version php, dont on a parlé au dessus.
 
WRInaute impliqué
Leonick a dit:
Dans quel cas est-on "obligé" de développer en objet ? quand on veut envoyer un résultat d'une fonction non linéaire. En entrée, ça n'est pas génant, il suffit d'avoir plusieurs variables, mais en sortie, en dehors de la possibilité de renvoyer un tableau, pas d'autre possibilité (sauf si on utilise des variables globales, mais bon :roll: )

avant c++ comment est-ce que c'était codé en c ? avec une structure passé en référence ... qu'est-ce qu'un objet ? une structure avec des méthodes ... Tout ceci ce code parfaitement en procédural et en php. Encore une fois la POO est une implémentation. Et la réponse de ce post est que la POO en php est déconseillé pour la performance ... çà se mesure facilement, instancier un objet çà a forcément un cout !
 
WRInaute accro
Tiens je viens de faire un test, ça prend en moyenne 40 microsecondes de plus de faire une instantiation et d'utiliser une méthode que de juste utiliser une fonction. C'est une classe avec une petite méthode qui est la même que la fonction utilisée. Dans une boucle de 100000 tests, ça donne une différence entre 3 et 5centièmes de seconde ... Faut pas oublier qu'on instantie qu'une fois aussi, on va pas boucler sur une instantiation juste pour exécuter une méthode. A bah oui ça a un impact sur les performances, c'est fou ... En fait ça a plus un impact de coder comme un porc, d'utiliser les fonctions qu'il ne faut pas utiliser suivant la situation, ou bien de faire n'importe quoi avec la concaténation de chaines de caractères et de variables, ou bien encore de calculer à chaque itération de boucle une valeur statique, de pas utiliser de cache quand c'est necessaire, d'utiliser trop de variables quand une requête suffit, d'oublier les indexs sur certains champs importants, blablabla ...

Le prix à payer pour la liberté est quand même très léger :mrgreen:
 
WRInaute accro
YoyoS a dit:
Faut pas oublier qu'on instancie qu'une fois aussi, on va pas boucler sur une instanciation juste pour exécuter une méthode.
du moins si ton client n'achète qu'un seul produit sur ton site e-commerce :(
S'il en achète plusieurs :D il faudra instancier autant d'objets "produits" qu'il aurait de produits dans son caddie
En fait, le gros problème c'est que pour utiliser une simple fonction, on est obligé de charger la totalité de la bibliothèque considéré et ça c'est consommateur de ressources.
Mais la POO ça n'est pas que pour le PHP, il y a aussi le js. Et quand on voit le poids des librairies à charger juste pour afficher une simple image en version agrandie, c'est les navigateurs qui en pâtissent. Mais là aussi, on a l'effet web 2.0 :lol:
 
WRInaute accro
Quoi ?? Tu ferais un objet par produit ? Roooh :mrgreen: Un simple tableau d'entiers dans une classe suffirait :/

Je te signale que toutes les fonctions que tu fais, tu les charges aussi en mémoire avant de faire toute exécution. Quand tu fais une instantiation de classe, c'est pas à ce moment la qu'il va tout charger en mémoire, il va charger en mémoire seulement les parties qui doivent être uniques pour chaque instantiation de classes.
 
WRInaute impliqué
YoyoS a dit:
Fais en une utile et 100x plus grosse, on verra après :mrgreen:
pareil pour ton test, avec de l'héritage, des constructeurs en cascade et avec toute la panoplie du très bon développeur objet qui utilise ce concept jusqu'au bout :D
 
WRInaute accro
hehe :) Pas envie parce que je vois pas comment je pourrais transformer une classe de ce type en de simples fonctions lol. Il y aurait de la redondance à mort et puis, faut quand même être fou pour défaire de si belles classes dont tu parles en simple fonctions :mrgreen:

Au fait j'y pense, je charge pas toutes mes classes et librairies en mémoire à chaque page. Il y a une fonction qui s'occupe d'aller chercher le bon fichier avec la bonne classe dès que tu l'instanties, pratique :mrgreen:

par exemple:

Code:
function __autoload ($class_name) {
	require_once('mesclasses/'.$class_name.'.php');	
}

Vos fonctions sont toutes en mémoires à vous (ou en tout cas leurs prototypes) :oops: Pas taper trop fort :arrow:
 
WRInaute impliqué
ça me fait penser à un gars qui dirait moi je fais que du récursif parce que c'est plus stylé et l'autre qui lui répondrait moi je fais tout en itératif car je cela consomme bcp moins de mémoire...
 
WRInaute accro
YoyoS a dit:
Quoi ?? Tu ferais un objet par produit ? Roooh :mrgreen: Un simple tableau d'entiers dans une classe suffirait :/
oui, si tu n'as besoin que de l'id du produit
YoyoS a dit:
Je te signale que toutes les fonctions que tu fais, tu les charges aussi en mémoire avant de faire toute exécution.
non, car tu ne charges que les bibliothèques dont tu as besoin.
Hé oui, même en mode procédural on peut faire des bibliothèques 8)
 
WRInaute accro
Oula viens de voir la suite, je m'en prends plein la gueule :D On va arrêter là, j'ai compris qu'on tournait en rond. En php, faut pas croire que je ne fais que de l'orienté objet hein, si j'ai un petit script d'une page à faire tourner en tâche cron, j'vais pas m'amuser à faire ça en orienté objet. Par contre pour un gros site, ou un site que je veux rendre complètement modulable, je préfère le faire en POO, après si vous voulez pas c'est votre choix. Actuellement je développe un jeu en php, ajax et compagnie depuis plusieurs mois et je suis content de l'avoir commencé directement en orienté objet car je suis sur que j'aurais galéré pour ajouter de nouveaux modules par la suite ou encore après une pause d'une semaine pour reprendre là ou j'en étais.

Et si j'ai besoin de plus d'info qu'un tableau d'entier, et bien dans ma classe je fou un tableau d'objets dans ce cas, pas plus compliqué :). Ensuite, pour y accéder, tellement plus simple qu'en procédural, surtout avec de bons outils.
$macommande = new Commande($idClient,...,...);
$macommande->addProduit(1,'Gant');
$macommande->addProduit(2,'Apprendre POO');

Et plus tard:
$macommande->calculerRemise($codeReduc);
$macommande->getTTC();
$macommande->getNbProduits();
//tu peux boucler maintenant stu veux ;)
$macommande->getTabProduits(1)->getPrix();
$macommande->getTabProduits(1)->getBlabla();

Ca fait quand même un code plus clair non ? Tu trouves pas que c'est plus lisible et que ça a pas besoin de commentaires ? Même un infographiste attardé de la programmation comprendra ce qu'il se passe :/

Et gérer des bibliothèques en procédural pour charger ce dont on a besoin seulement quand on en a besoin, je vois pas trop comment faire sans y aller manuellement ?

Enfin voila, chacun ses choix :)
 
WRInaute impliqué
$commande = array(
"idClient" => 123456,
...
);

CreateCommand( $commande );

$product1 = array(
"idProduct" => 1,
"nomProduct" => "Gant"
);

$product2 = array(
"idProduct" => 2,
"nomProduct" => "Apprendre à coder"
);

AddProductCommand( $commande, $product1 );
AddProductCommand( $commande, $product2 );

Et plus tard:
GetTTCCommand( $commande );
GetNbProduits( $commande );
//tu peux boucler maintenant stu veux ;)
$produit1 = GetTabProduits( $commande, 1 );
GetPrixProduits( $produit1 );
GetBlabla( $produit1 );

1/ l'objet n'est qu'une implémentation
2/ le procédurale est d'une manière générale plus performant (encore plus vrai en php4, à cause de la copie systématique)
3/ l'objet dans un certain langage plus stricte oblige à mieux coder, mais pas en php ($this->toto...)

;-)
 
WRInaute accro
Merci pour la version procédurale mais bon, c'est pas vraiment ce que j'attendais. Tout ce que je veux c'est que vous admettiez ce qu'apporte la POO. Le reste je m'en tape un peu ;)

Note que tu dois faire les déclarations de tous les tableaux, variables,etc manuellement alors qu'en POO, tu ne fais qu'une instantiation, ce qui va automatiquement réserver de l'espace mémoire pour les variables déclarées dans la classe. Ce qui engendre un éclaircissement du code dans l'espace de travail. Tu évites le code dupliqué vu que tout est déclaré une fois dans ta classe, tu as une plus grande facilité de maintenance et par conséquence, moins exposé aux erreurs.

Autre avantage, toi tu fais un get, pour peu que t'ais un gros site, tu te retrouves avec un menu de 10000fonctions ? C'est justement sur la grosseur du projet que tu vois le bénéfice de la POO. Ce que j'aime bien c'est que justement à partir d'un objet commande dans notre cas, tu peux accéder à des ramifications de cet objet avec directement toutes les fonctions dont tu as besoin et qui sont en rapport direct avec cet objet. Pas obligé de donner des noms de fonction getCommandeTabPrix() vu qu'on est déjà dans une spécialisation d'un objet commande ne comportant que des fonctions s'y rapportant, donc getPrix() suffit.

Et ca me fait rire que tu dises que l'implémentation procédurale est globalement plus rapide que l'objet car en fait on s'en fou royalement. Le php est un langage extrêmement lent par rapport à du C par exemple. Il n'a pas la même vocation et c'est plus un langage utilisé comme traitement intelligent en arrière plan par rapport aux actions d'un utilisateur. Si l'utilisateur ne voit aucune différence dans le temps d'exécution, et bah c'est même pas la peine de mentionner un problème (qui n'en est pas un) au niveau de la vitesse d'exécution ;)

Après c'est sur que tu peux tout faire en simple fonctions, jamais dit le contraire. Tu peux tout faire sans fonctions aussi, c'est possible, sisi je vous assure :D, et c'est obligatoirement plus rapide vu qu'il y a moins d'interruptions pour les appels de fonctions. A merde j'vais m'y mettre je crois pour gagner 40 microsecondes :D.

Par contre, faut qu'on continue ou bien vous voyez toujours pas ce que le POO peut amener de + dans les gros projets ? J'ai peut-être écrit tout ça dans le vide ? Il va me ressortir un code en procédural rien que pour me faire chier :mrgreen:
 
WRInaute accro
Mais ça a rien avoir, tu me parles d'une norme alors que je te parle d'une implémentation. Pffff

Allez j'en ai marre là, vous me décevez. C'était mon dernier post aussi long je crois :/
 
WRInaute impliqué
shelcko a dit:
En fait on s'éloigne du sujet de départ en fait je voulais avoir une idée de la perte de perf engendrée par la POO par rapport à la prog procédurale. Je crois que je vais faire des test pour me rendre compte par moi même.
Merci quand même.

ouai en faite shelcko s'était répondu de lui même dès le début, c'etait pas la peine d'écrire ces 4 pages :-D

ensuite c'est vrai que webrankinfo c'est plus du conseil pour des sites web amateurs, mais sache qu'il y a des sites qui fassent à leur monté en puissance ont le choix entre acheté n milliers d'euro de serveur, ou d'optimiser l'applicatif, y compris l'interface en php, pour que cela tienne ...

YoyoS a dit:
Par contre, faut qu'on continue ou bien vous voyez toujours pas ce que le POO peut amener de + dans les gros projets ?

là par contre c'est prendre le problème à l'envers, c'est l'analyse nécessaire au préalable pour les gros projets et notamment les méthode d'analyse objet qui vont aboutir généralement à une implémentation objet mais c'est pas obligatoire.

(3ème édition)
 
WRInaute accro
YoyoS a dit:
Mais ça a rien avoir, tu me parles d'une norme alors que je te parle d'une implémentation. Pffff
j'avais oublié de mettre le :mrgreen:
En clair, le semi POO implémenté sur PHP n'oblige aucunement à avoir un code plus propre et lisible (ce qui n'est pas obligatoirement lié).
Pour avoir un code plus propre, il faut un typage fort des variables, là ça oblige vraiment à programmer correctement, ensuite pour avoir des objets plus facilement transportables, rien de mieux que d'avoir un vrai langage objet qui autorise le polymorphisme. Et ce ne sont que 2 des points faibles de la POO en PHP

Après, c'est à chacun de voir.
Mais dans de nombreux cas, savoir quand utiliser de l'objet et quand faire du procédural est la meilleure méthode IMHO
Si on doit utiliser une procédure dans plusieurs "objets" alors on va se dire "pourquoi pas l'implémenter dans un objet de base dont chacun des autres objets héritera ?" et on se retrouve ainsi avec une usine à gaz.
Ca me fait vraiment penser aux moteurs de templates dont on essaie de faire croire qu'ils arrivent, eux, à faire du vrai MVC, alors qu'ils ne rajoutent qu'un niveau supplémentaire avec leur pseudo-langage.

Donc, je suppose que tous tes développements sont en objets, y compris les js ?
 
WRInaute occasionnel
Pffiou 8O ça c'est du débat !

Vous m'avez l'air plutôt calé, alors pourriez vous me donner l'adresse de votre bible php POO ? Ou encore mieux le lien du tuto qui vous à fait découvrir et appris la chose ?

Par avance merci :)
 
WRInaute accro
antinomx a dit:
Pffiou 8O ça c'est du débat !

Vous m'avez l'air plutôt calé, alors pourriez vous me donner l'adresse de votre bible php POO ? Ou encore mieux le lien du tuto qui vous à fait découvrir et appris la chose ?
j'ai appris la POO (la vraie, en java :wink: ) quand j'ai repris les cours à la fac
Sinon, pour le php, developpez.com font de bons tutoriaux voir http://hachesse.developpez.com/objetphp/
 
WRInaute accro
julienr a dit:
mais sache qu'il y a des sites qui fassent à leur monté en puissance ont le choix entre acheté n milliers d'euro de serveur, ou d'optimiser l'applicatif, y compris l'interface en php, pour que cela tienne ...

Si t'en viens à supprimer la POO parce que c'est ta dernière option pour optimiser ton serveur, il y a un sacré problème. Soit ton ou tes serveurs n'étaient pas assez gros, ou nombreux, ou la répartition des charges n'était pas bonne. Mais jamais tu vas supprimer la POO pour gagner des perfs ... Quand tu dis optimiser php, j'imagine que c'est simplement faire tout ce que j'ai cité avant, autre que toucher à l'implémentation (si elle a été faite correctement évidemment) ? Genre utiliser les bonnes fonctions, ne pas faire de requêtes inutiles, indexes, etc ?

Sinon Leonick, je suis d'accord que dans certains cas la POO n'est pas nécessaire, on en a déjà discuté.

Je suis aussi au courant qu'il n'y a pas encore de polymorphisme et de typages fort. Ca va même ensemble ;) Si tu as un typage faible, t'as pas besoin du polymorphisme. la POO en php n'est pas aussi poussée qu'en Java et C++, je suis d'accord, j'ai commencé par ces langages pour l'apprendre mais ça n'enlève rien aux avantages de l'utiliser sans polymorphisme. C'est sur que ce sera un plus quand il sera là (j'ai pas regardé ce que fait PHP6 encore), mais en attendanton bénéficie de tous les avantages de la poo avec ce qu'on a actuellement.

Concernant ton exemple d'objet englobant tout, ça c'est mal coder encore une fois, tu peux toujours optimiser même en POO. Si tu dois utiliser une même fonction dans plein de classes différentes c'est qu'il y a un problème d'analyse, c'est tout :/

Et pour la question au sujet de mon développement Javascript, c'est oui et non. J'ai commencé par faire tout manuellement. Ca prend énormément de temps de tout régler pour chaque navigateur, je suis vite passé à un framework. J'ai testé prototype et jQuery, ils sont bien tous les deux ! Par contre, mes développements ne sont pas assez gros et je ne fais pas d'orienté objet, seulement du procédural en Js. Les frameworks fournissent des objets mais je n'en construit pas moi même. Au niveau des performances je ne connais pas l'impact concernant le js. Intéressant d'en discuter ;)
 
Nouveau WRInaute
Re re tout le monde,

Pour le code ou les perfs, regardez aussi du coté des fonctions
__sleep() ,
__autoload() (déjà citée plus haut), spl_autload() qui enlèvent déjà une bonne partie des require et/ou include
et la sérialisation des objets

Quand on parle de POO, il ne faut pas uniquement se limiter aux bouts de code non plus.
Il existe aussi des concepts liés à la POO qui ne sont pas à négliger et qui, d'expérience, sont bien plus pratiques.
Je pense notamment au modèle MVC (Model - View - Controller) qui sépare très bien le code (intelligence du prog), les données (DB), et la présentation des données... et faire du vrai MVC en procédural pour moi c'est simplement impossible. On peut juste s'en approcher.
Oui MVC est aussi un état d'esprit ... mais lors du refactoring d'une application, on voit vraiment les gains que cela peut apporter.
Si demain on veut adapter un site pour les mobiles ou transférer des données en XML à une app tierce, changer le design complet d'un site, passer de mysql à postgresql , tout cela se fait très facilement,étant donné que les couches sont indépendantes.

Modèle MVC => http://fr.wikipedia.org/wiki/Modèle-Vue-Contrôleur
Smalltalk => http://fr.wikipedia.org/wiki/Smalltalk
Refactoring => http://fr.wikipedia.org/wiki/Refactoring

J'ai développé un application web pendant 2 ans et pendant tout ce temps le marché à changé et l'application a du évoluer en fonction pour être à jour lors de la sortie. Merci le MVC.

Je suis aussi passé par la prog PHP procédurale et j'étais septique pour franchir le pas à la POO... mais voilà, plus de retour en arrière possible pour moi.

Mais étant donné que PHP n'est pas un language pur OO, un passage par Java ou C++ est très bien avant de commencer en PHP.
 
WRInaute accro
ManuxBE a dit:
Je pense notamment au modèle MVC (Model - View - Controller)
sauf que même en java, je n'ai pas vu, pour une application un tant soit peu complexe un MVC pur. Il y a toujours un mélange.
ManuxBE a dit:
Oui MVC est aussi un état d'esprit ... mais lors du refactoring d'une application, on voit vraiment les gains que cela peut apporter.
Si demain on veut adapter un site pour les mobiles ou transférer des données en XML à une app tierce, changer le design complet d'un site, passer de mysql à postgresql , tout cela se fait très facilement,étant donné que les couches sont indépendantes.
et là, POO ou procédural, ça ne change rien. Il faut juste que ça soit bien développé pour avoir une bonne évolutivité
 
WRInaute passionné
Hello,

and Sorry for lagging ... (je prévoyais de répondre à ce post depuis quelques temps)

shelcko a dit:
Bonjour,
Je suis en train de commencer un nouveau site et je me demande s'il vaut mieux le développer PHP Orienté Objet ou en procédural.
En fait c'est un site ou il n'y aura qu'un développeur (moi) et il sera pas très complexe au niveau prog. Mais s'il est un peu fréquenté (ce que j'espère comme tout créateur de site :wink: ) il consommera un pas mal de ressources d'où cette question sur l'optimisation de mon code. :?:
Merci d'avance pour vos conseils. :D

Tout d'abord c'est le bon moment pour ce poser ce type de question, parce qu'il y a encore à peine quelques années, la question de la POO était une idéologie et la seule idée de se poser la question de savoir si le design OO est adapté à tout les cas, était la garantie d'avoir « des problèmes ».

Je vais répondre à propos de la POO en général, vu que PHP n'est pas un langage que j'apprécie personellement.

La POO recouvre plusieurs concepts : masquage des caractères privés ou d'accès limité, modularisation, liaison dynamique et typage.

La première chose que l'on peut remarquer, c'est que l'on peut parler de la POO en énoçant une liste d'aspects... qui peuvent tout à fait être appréhender indépendament les un des autres. Plus que cela même, on peut par exemple avoir besoin de certaines capacité avancés comme les hierarchie de type, sans avoir besoin de masquage d'accès ou de liaison dynamique.

La POO est un peu comme AJAX : elle n'est pas une science en elle même, mais elle est un mixe de plusieurs techniques. Ce n'est pas un problème en soit, mais le problème vient quand on confond ces deux notions avec un tout atomique. Dire « je fais de la POO » n'a presque pas plus de sense que de dire « je fais de l'AJAX » (ce n'est pas par hasard si un langage d'ingénierie comme Ada, préfére ne pas tous mélanger, ... distinction qui n'a rien de limitative, mais permet de savoir de quoi on parle et pourquoi on l'utilise).

Et parfois, quand il est utile de distinguer les choses, la POO peut poser problèmes. En effet, dans les langages OO qui mêlent tous les concepts précédements cités sous une même notion, lorsque cette notion est employée, on ne perçois pas toujours pourquoi ni ce qui était recherché parmis tout ce que recouvre cette notion.

Dans ce domaine, l'approche Ada, qui justement distingue tous ces concept séparement est assez interessante. D'ailleurs beaucoup de gens ne savent pas que les design que permettent la POO sont aussi possible en Ada, même s'il n'y a pas en Ada, des classes dans le sense des autres langages (il n'existe dans ce langage, aucun mot réservé « class » ).

Finalement, ce qui est important, c'est de savoir, ce qui dans la POO va être utile. Dans les langages trés orienté classes (certains même, comme Eiffel, ne conaissent que cette unique notion et aucun autre choix n'est possible : dans ces langages, la « classe » est une chose-à-tout-faire), il faudra de toutes manière passer par des classes, parce qu'il n'existera aucune autre alternative. Mais si la question de savoir quel et quel aspect de la POO sont recherché pour tel ou tel design, alors il sera interessant de clairement le documenter dans les commentaires accompagnant la classe. Par exemple, si une classe est créé comme point de départ d'une hierarchie de types seulement, et que la liaison dynamique n'est absoluement pas souhaitée, il faudra le préciser dans un commentaire documentant la classe, car sinon, comme tout est « classe » qui mélange tout ces concepts, on ne pourra deviner lesquels sont ciblés.

Une autre appréciation personelle maintenant, que je vais tenter d'exposer en peu de mots mais de manière compréhensible : la POO, c'est organiser un design avec des boites, les fameuses boites noires. Mais il n'est pas toujours possible de bien représenter un design de cette manière, et une propriété ou une caractéristique d'une application pourra ne pas toujours être circonscrite à une classe, mais plutôt devoir être répartie en plusieurs lieu du code de l'application. Ou alors, si on tente de prendre une caractéristique de l'application et de la circonscrire à une classe, cela va exiger une réorganisation de l'application qui souvent désorganisera tout le reste (un de ces cas où l'on n'arrive pas tout faire rentrer dans un même système de contraintes, sinon il y a rebellion).

L'idéal quand il n'est pas possible de circonscrire un aspect ou une caractéristique d'une application à une classe, serait d'itenfier clairement comme tel les zone du source de l'application, qui peuvent se trouver distribuer en plusieurs points, comme participant à tel ou tel caractéristique.

Là où je veux en venir, c'est à ceci : quand il n'est pas possible de tout mettre dans des boites noires connectées entre elles, il est possible de penser en terme de calques, comme on le ferait quand on dessine avec un logiciel comme PhotoShop ou Gimp : une partie de l'implémentation peut apparaître distribué en plusieurs endroits dans le dessin général de la conception, mais cela n'empêche pas de l'isoler dans un calque (conceptuellement).

Malheureusement, je ne connais aucune langage offrant un support pour ce type de design (pas d'autres choix que de se reporter sur des commentaires plus ou moins formalisés).

Alors POO ou pas POO ? La question n'a pas de réponse, le mieux et de s'en munir comme d'un outil et savoir l'invoquer à bon escient. L'erreur serait plutôt d'en faire un dogme indiscutable comme ce fut le cas dans le passé (la POO ne fait pas de la magie et ne fait pas de miracles).

(tout ça pour finir en réponse de normand : pt'être ben qu'oui ou pt'être ben qu'non)
 
WRInaute accro
Oue ta conclusion rejoint ce qu'on dit depuis le début quoi. Mais t'as complètement zappé la question principale quand même. Et les performances dans tout ça ?
 
WRInaute passionné
YoyoS a dit:
Oue ta conclusion rejoint ce qu'on dit depuis le début quoi.
Peut-être qu'elle interessera certaines personnes (il y a des éléments nouveaux dans ce post quand-même).

YoyoS a dit:
Mais t'as complètement zappé la question principale quand même. Et les performances dans tout ça ?
Je n'avais pas saisie que la question était dans les performances, mais alors si c'est le cas, il faut peut-être ne pas voir la question sous l'angle POO vs non-POO, mais plutôt voir les différentes manière déployer. Et question efficacité, je ne suis pas certain que PHP soit de toute manière ce qu'il y a de mieux, car interprété.

Je n'ai jamais rien vue qui démontrait que la POO va dans le sense ou le sense contraire de l'efficacité, je ne sais même pas si cette question est décidable dans l'absolue (je ne pense pas personellement)
 
WRInaute passionné
Pour accélérer PHP on peut aussi le pré-interpréter.

Et pour avoir bosser sur des applis Java & PHP, je trouve Java plus lent car demandant bien trop de couches logiciel.
Après je suppose qu'il y a 1000 contre exemples dans un sens comme dans l'autre.

Et surtout plein de langages moins connus (Python par exemple) très performant.
 
WRInaute accro
Bacteries a dit:
Et pour avoir bosser sur des applis Java & PHP, je trouve Java plus lent car demandant bien trop de couches logiciel.
en fait, java optimise le bytecode au court de la 1° utilisation de chacune des parties du code. Et donc, théoriquement, la vitesse est sensée s'améliorer ensuite. J'avais légèrement remarqué ça, mais je n'ai jamais fait de tests approfondis, et encore moins, sur de grosses applis
 
Discussions similaires
Haut