Forum d'entraide PHPFrance

bonjours
Je voulai savoir par rapport à la POO que j'aime pas dutout,
si c'est pas mieux de faire dabord le script en procédural
puis de l'adapté à la fàçon poo
plutot que de faire directement en poo
et savoir comment vous faite
merci

On ne pense pas de la même façon quand on fait un programme procédural et un programme objet...
Donc on fait soit l'un soit l'autre, mais c'est souvent une plaie de passer de l'un à l'autre.

salut,

première chose, tu n'est absolument pas obligé d'utiliser la poo tu peux très bien tout faire en procédural ce n'est pas un problème (dans certaine limite).

sachant que, dans la plus part des cas et ici souvent le web) le script php est exécuté séquentiellement des fonctions font très bien l'affaire.

la poo en php amène les mêmes choses que dans les autres langages, modélisation, héritage etc

si tu n'en a pas besoin ne t'emmerde pas avec ça surtout si tu n'aime pas.

sinon penser procédural ou objet ce n'est pas la même chose.

si tu veux développez en objet modélise ton application (avec uml par exemple http://www.commentcamarche.net/contents ... class.php3 et des centaines d'autres sur le web) après tu code les classes.

les nouvelles moutures de php tendent a augmenter l'utilisation de classe (toutes les nouvelles fonctionnalités sont développées en classe, regarde PDO, la SPL etc etc) mais rien ne t’empêche de ne pas les utiliser

@+

Ou tu peux y aller progressivement et faire une partie de ton code en procédural et une autre en objet. En fait toutes les options sont possibles, excepté pour des projet compliqués et un travail en équipe où il faut pouvoir se reposer sur des normes.

Un objet en réalité c'est rien d'autre qu'un regroupement de fonction et de variable qu'on apelle apelle d'une certaine maniére , le seul avantage d'aprés moi c'est l'héritage mais je voix pas vraiment l'utilité dans un site e commerce
puis pour la lisibilité je voix pas nomplus l'utilité car on peux faire encore mieux en fesant des commantaire et des inclusions de fichier pour chaque traitement d'information
merci pour vos réponse A+

C'est heureusement un peu plus que ça, mais comme cela a été dit plus haut, c'est surtout une question de projet

Concernant l'héritage, pour ton site e-commerce, et bien à moins que tes articles soient tous identiques (ex : uniquement des livres), les caractéristiques d'un lave vaisselle et d'un dvd ne seront pas les mêmes... et pourtant ce seront tous deux des articles que tu pourras ajouter à ton panier etc. donc l'héritage peut être intéressant.

L'encapsulation te permet de réunir dans une même entité les données et les moyens de les gérer, à savoir les attributs et les méthodes. Ainsi, au lieu d'une fonction générique demarrer() pouvant être utilisé n'importe comment, tu peux spécifier que la méthode demarrer() est liée uniquement aux objets de type "voiture", ce qui évitera que quelqu'un puisse essayer de démarrer une chaise ou un escalier. Une fois encore pour un site d'e-commerce, un dvd aura peut être une bande annonce (qui sera bien moins intéressante pour le lave vaisselle).

Enfin, le polymorphisme, te permet de redéfinir des méthodes liées à l'héritage. Ainsi, si l'on considère un objet Article et ses descendants DVD et LV possédant tous une méthode enregistrerEnBaseDeDonnees(), le système appellera la fonction enregistrerEnBaseDeDonnees() spécifique suivant que l'article est un DVD ou un lave vaisselle.

Un autre avantage de l'objet, c'est la ré-utilisabilité dans la mesure où ta classe va pouvoir servir à aux autres développeurs du projet. Pour des projets en équipe (ou tout simplement pour limiter les risques d'erreur), la visibilité des attributs et des méthodes peut aussi être très utile en obligeant celui qui utilises ton objet à passer là où toi tu l'autorises pour ne pas faire n'importe quoi (genre ne pas mettre la liste des acteurs dans le champ date de sortie)

Faut vraiment voir cela comme une autre façon de coder, avec ses avantages et ses inconvénients.. une fois encore tout dépend du projet (une cabane en brique c'est plus solide qu'une cabane en bois, mais ça tiendra jamais en haut d'un arbre...)

Je voix pas pourquoi c'est dure de passer du procédurale à l'objet puisque les classe sont coder en procédurale

Essai de faire appel a des équivalents des propriétés d'une classe. Des variables globales tu me dira oui mais qu'est ce qui empêche de les modifier par autres choses ?

Comment gère tu la persistance des donnée ? Une fois la fonction exécutée tu ne peux plus utiliser ce qu'il y a dedans or un objet est une représentation de quelque chose de "réel" et tu peux interférer dessus, tu passe ton objet d'un script a un autre.

Imagine un yeux de courses auto, tu utilise la méthode accélérer et la propriétés vitesse tu garde la vitesse de script en script sans problème pour faire la meme chose en procédurale tu utiliserais un tableau structuré qui n'est, au final un objet moins évolué.

Dans le cas d'un script e commerce, comme indiqué avant tu a, par exemple, un objet panier qui a un méthode ajoutarticle (suppressionarticle, modificationarticle etc etc).
Cette méthode prend en paramètre un objet article et la quantité.
A partir de la le caddie n'a pas besoin de savoir ciment est foutu l'article du moment qu'il peux accéder au prix et l'article se fou royalement de ce le caddie (ou qui que de soit) va faire du prix qu'on lui demande.
Au final tu a objet qui garde les données (la panier) tu le passe de page comme tu passerais un tableau en session mais tu devrais avoir des fonctions auquelles tu passée tableau en paramètre, tu devrais le gérer dans la gestion du formulaire etc etc.

Maintenant au vu de tes réponses je pense que tu est sur : l'objet c'est de la merde.
Si c'est le cas, comme tout le monde te l'a dit reste en procédural ça fonctionne aussi et dans le cas ou tu développe tous seul c'est pas un problème.
Sache simplement que la notion se retrouve dans tous ce qui développement que ce soit un language tel le c ou java mais aussi dans les sgbdr. Si l'on modélise les applications c'est pour avoir des chose "robuste" et maintenable a plusieurs sans se prendre la tête a savoir ce qu'à fait le mec d'a cote pour pouvoir pondre ses 3 lignes de code.

Tu peux aussi, sûrement. faire ton site oueb en assembleur mais cela sera Moins aisé

Essai aussi des language "full object" comme on dit, tel python ou java tu pourra voir la différence.

Mais en aucun cas ne te lance dans de l'objet si c'est pour faire comme tout le monde XD

@+

Je voix pas pourquoi c'est dure de passer du procédurale à l'objet puisque les classe sont coder en procédurale

C'est pas plus dur que de passer d'une voiture à boite de vitesse manuelle vers une voiture à boite automatique ... y a toujours un volant et 4 roues... par contre tu vas piler un certain nombre de fois avant de t'habituer au fait que la pédale de gauche ne sert pas à débrayer

Je voix pas pourquoi c'est dure de passer du procédurale à l'objet puisque les classe sont coder en procédurale

Le paradigme même est complètement différent. L'objet permet un degré d'abstraction, d'indépendance du code qui rend tout travail par après bien plus facile (si correctement employé, sinon c'est pareil voir pire).

Imagine que dans un site e-commerce, tu dois gérer plusieurs types de cartes de crédit. Si chaque type de carte possède sa classe, tu peux utiliser ce qu'on appelle en conception objet un "factory", pour obtenir le bon type de classe sans que le reste de ton programme n'en soit conscient.

Genre, un bout de code, a titre d'exemple:

// $card_data comprend toutes les données envoyées par le formulaire de paiement.
// c'est "l'usine" qui s'occupe de choisir la bonne classe, nous on ne s'en occupe pas.

$card = card_factory::new_card($card_data);
if (!$card->is_valid())
  {
  // gestion d'erreur
  }

$card->invoice_amount('500')
     ->invoice_currency('euro');

if (!$card->payment_succes())
  {
  // gestion d'erreur
  }

Si une carte venait a changer (méthode de validation par ex.) ou si un nouveau type de carte venait à être supporté, ce bout de code resterait entièrement inchangé.
Pour ajouter un nouveau type de carte, il suffirait d'ajouter sa classe, et de le mentionner dans le fichier de configuration (que l'usine utilise pour détecter le type de carte). Aucune risque de modifier ou de devoir toucher un bout de code préexistant.
Activer ou désactiver un type de carte reviendrait à l'insérer ou pas dans le fichier de configuration, le reste du site étant tout à fait imperturbable quant à la diversité et le type de cartes supportées.


Et il n'y a pas que le procédural et l'objet (qui eux-même se subdivisent en familles). Il y a aussi le fonctionnel (Ha, essaie toujours de faire du traitement parallèle ou distribué sans perdre de cheveux avec du procédural), le déclaratif (Sql, Html...), par aspect, par contrainte, logique, etc.. C'est un peu le fouillis, puisqu'un paradigme n'empêche pas l'autre, mais en gros le meilleur c'est d'en connaître plusieurs, afin de pouvoir choisir, le cas échéant, le meilleur outil pour l'objectif a accomplir.

un language tel le c ou java

Juste pour digresser, mais C est impératif. Ce qui n'a pas empêche un certain J. Carmack d'employer du polymorphisme..

Ok merci pour vos réponses, j'ai du mal à changer mes habitude mais là malheuresement je vais devoir apprendre et surtout m'entrainer à faire de la poo avec php car malheuresement c'est l'avenir
A+

Ok merci pour vos réponses, j'ai du mal à changer mes habitude mais là malheuresement je vais devoir apprendre et surtout m'entrainer à faire de la poo avec php car malheuresement c'est l'avenir
A+

Ce n'est pas plus l'avenir que le procédural. ^^
Cela dépend de ce que tu as à développer. Certains programmes sont d'une difficulté à sauter par la fenêtre en POO alors qu'ils sont logiques en Procédural, et bien sûr on trouve des exemples inverses.

J'ai cru comprendre que php sera de plus en plus orienté objet

De nombreuses librairies passent à l'objet oui, mais PHP en lui même reste sur une base procédurale.
Le jour où on ne pourra plus faire de chaîne de caractère sans instancier un objet String on en reparlera.