8731 sujets

Développement web côté serveur, CMS

Qui utilise la programmation orientée objet en PHP ?

Pages :
(reprise du message précédent)

PanPan50 a écrit :
Enfin bon il faudrait peut-être que je me force à l'utiliser, tout le monde à l'air de dire que c'est LA façon de bien coder...


Je pense qu'il faut commencer par comprendre l'utilité du MVC.

Sur des petits projets, ça peut paraître inutile (même si ça ne l'est jamais), mais quand tu arrive sur des gros projets, en équipe avec une maintenance sur le long terme, c'est inévitable, sinon ça risque de finir par des homicides volontaires, torture, etc...

Le but c'est de dissocier les données (Modèle, BDD) de la couche métier (Contrôleur, Code PHP, Java, etc...) et de l'interface visuelle (Vue, HTML, CSS, etc...). de manière à ce qu'un intégrateur par exemple qui ne connait pas le PHP ait une meilleur lisibilité et ne risque pas de détériorer l'application. De la même façon, si tu change un fichier HTML, tu a pas besoin de te farcir a nouveau tout le code PHP.

Perso j'ai poussé le vice jusqu'à ne plus avoir une seule ligne de PHP dans mes fichiers HTML et c'est un bonheur à travailler.

Pour ce qui est de la relation Modèle - Contrôleur, il y a par exemple Doctrine 2 (ORM de Symfony 2) qui possède des classes de type "Entity" (classes métier) et des classes de type "Repository" (classes d'interaction avec la BDD), mais quand tu crée ton appli, tu n'est absolument pas obligé de les utiliser, tu peut mixer ton modèle et ton contrôleur au sein de la même classe.
Modifié par JJK801 (02 Aug 2012 - 17:33)
C'est peut-être contrôleur modèle qui me pose le plus de soucis de compréhension en effet....

Sinon je travaille uniquement sur des projets perso et de très petite taille, mais peu importe la technique m'intéresse !
PanPan50 a écrit :
C'est peut-être contrôleur modèle qui me pose le plus de soucis de compréhension en effet....

Sinon je travaille uniquement sur des projets perso et de très petite taille, mais peu importe la technique m'intéresse !


Pour simplifier, le modèle c'est ce qui te sert à récupérer tes données (Requêtes SQL, lecture de fichiers, etc...) et le contrôleur te sert à les placer ou tu veut après les avoir récupérer (entre autres choses).

Quand je dit "Récupérer tes données", je sous entends:

-Se connecter à la source
-Importer les données
-Formater les données
-Renvoyer les données au bon format
Modifié par JJK801 (02 Aug 2012 - 17:51)
Il va falloir que je me lance, je pense que c'est le meilleur moyen de se forcer !

Encore merci pour ces explications.
Bonjour !
Si ça peux vous rassurer les jeunes développeurs (par exemple : moi) ont appris à dév directement en objet sans passer par la couche spaghetti ! Et quand j'ai commencé PHP c'était déjà objet, donc j'ai commencé PHP en objet.
J’adore PHP pour la liberté qu'il offre ce qui peu aussi être un problème pour le développeur qui ne connait pas les *bonnes pratiques*.
Les bonnes pratiques je les ai appris ici en spammant les utilisateurs aguerris (merci jb_gfx, raphaël, fvsch,Tony Monast,Heyoan, *edit : * Laurie-Anne ) de questions, du genre : "j'aimerai faire comme ça, est ce que c'est bien ?" et après un ou deux ans de calibrage je peux maintenant conseiller à mon tour.

Je regrette cependant énormément l'absence d'héritage multiple dans ce langage.
Modifié par Su4p (03 Aug 2012 - 15:15)
jb_gfx : Merci ^^, elle est devenue bleu aussi !
Modifié par Su4p (03 Aug 2012 - 15:18)
Modérateur
Bonjour,

Su4p a écrit :

Si ça peux vous rassurer les jeunes développeurs (par exemple : moi) ont appris à dév directement en objet sans passer par la couche spaghetti !


Attention de ne pas confondre la programmation spaghetti avec la programmation procédurale. Ce n'est pas du tout la même chose. Smiley cligne
Su4p a écrit :
Je regrette cependant énormément l'absence d'héritage multiple dans ce langage.

PHP 6 viendra un jour Smiley lol
JJK801 a écrit :
Perso j'ai poussé le vice jusqu'à ne plus avoir une seule ligne de PHP dans mes fichiers HTML et c'est un bonheur à travailler.

C'est ce que Symfony2 pousse (j'ai presque envie de dire oblige) à faire dans les vues, mais au final ça ne change à mon avis pas grand chose : On remplace php par TWIG (qui est très bien foutu cela dit). A moins que tu ne parles encore d'une autre technique avec uniquement du html sans aucun langage de template dans tes pages html ?

Dans un autre genre codeIgniter part du principe (à mon avis pas idiot) que php est déjà un bon moteur de template en lui-même et que ce n'est pas la peine de rajouter une couche par dessus. Et à l'usage c'est peut être un peu moins lisible mais même pour un intégrateur qui n'est pas un spécialiste du php je ne pense pas que ce soit tellement tellement plus compliqué : Quand on sait faire des conditions ou des boucles pour parser un tableau en twig, on sait le faire en php. En plus depuis php 5.4 on a toujours accès à <?= ?> même quand les shorttags sont désactivés, ça rend les vues un poil plus lisibles.

Après Je n'ai utilisé que Symfony2 avec twig et CodeIgniter, il existe peut-être des moteurs de templates plus simples ? Ou même plus performant que php seul ? Ou je n'ai peut-être pas bien exploité twig ?
Modifié par BlueScreenJunky (03 Aug 2012 - 18:05)
Tony Monast a écrit :
Bonjour,



Attention de ne pas confondre la programmation spaghetti avec la programmation procédurale. Ce n'est pas du tout la même chose. Smiley cligne


C'est vrai, (je viens de lire l'article Wikipedia sur la "Programmation spaghetti").....

*Wait for it *

Mais,
La programmation procédurale conduit souvent à du code spaghetti sur de grosses applications. Car elle n'est pas en soit une aide pour produire du code de qualité contrairement à la programmation objet qui elle, facilite cette démarche. Smiley sweatdrop

*Modération*

Il n'empêche qu'un développeur aguerrie dans cet art, soit par choix soit par contrainte technologique, peut produire du code procédurale de qualité. Smiley langue
Du moment que ça fonctionne en procédurale , et comme je sais que je travaillerai jamais en équipe car c'est pas ma spécialité , il est certain que j'utiliserai jamais la poo que je trouve dailleurs complétement inutile et si je serai patron j'interdirai son utilisation
Zed13 a écrit :
Avec PHP5.4, il y a déjà un simili d'héritage multiple avec les traits.

traits a écrit :

With traits the magic is endless !!



perfectionniste a écrit :
Bonjours à tous,

avec mysqli ont avait la fonction character_set_name() mais avec PDO comment faire (voir titre) ?

merci
Smiley ravi
Modérateur
Ca troll sec par là...

@perfectioniste : On peut se demander pourquoi un gang s'est amusé à pondre des algo pendant des semaines....

Le procédurale est intéressant pour les petites applications. On peut faire du bon taf en procédurale et avoir un code maintenable. Aussi en procédurale on peut très bien séparer les différentes couches d'abstractions.

Il y a une façon de contourner la problématique de l'héritage multiple en php. Il suffit de mettre en place une interface. Certes, c'est pas très propre d'un point vu sémantique, mais ça permet de contourner le problème.
niuxe a écrit :

Il y a une façon de contourner la problématique de l'héritage multiple en php. Il suffit de mettre en place une interface. Certes, c'est pas très propre d'un point vu sémantique, mais ça permet de contourner le problème.


Pas d'accord : l'utilisation des interfaces à la place de l’héritage t'oblige à redéfinir tes méthodes dans toutes tes sous-classes même si ce code est exactement le même.... pas très DRY Smiley ohwell
Par contre les traits pourraient bien être ce que je recherche (à vérifier), de plus PHP 5.4 est disponible chez ovh !!!
Bonjour,
Su4p a écrit :
Pas d'accord : l'utilisation des interfaces à la place de l’héritage t'oblige à redéfinir tes méthodes dans toutes tes sous-classes même si ce code est exactement le même.... pas très DRY Smiley ohwell
Par contre les traits pourraient bien être ce que je recherche (à vérifier), de plus PHP 5.4 est disponible chez ovh !!!

Je me suis retenu d'intervenir depuis la naissance de ce sujet, mais la somme de contre-sens accumulée risque de faire exploser des organes internes dont je comptais me servir encore quelques années.

Il faudrait un tutoriel complet sur l'objet, mais je n'ai ni le temps ni les compétences pour l'écrire.

Voici tout de même quelques pistes :

- Il existe deux modes d'héritage : l'héritage d'interface et l'héritage d'implémentation. Contrairement à ce qui est quasiment systématiquement appris aux débutants, le plus intéressant est l'héritage d'interface car il permet de découpler efficacement les composants logiciels. L'héritage d'implémentation couple fortement la classe mère et les classes dérivées, et les personnes qui ont quelques années d'expérience en POO sentent bien qu'il y a là quelque chose de malsain ; cette sensation est très proche de celle engendrée par la vue d'une variable globale.
- En ce qui concerne la factorisation de code, la composition permet de remplacer avantageusement l'héritage d'implémentation ; pas la peine de "redéfinir les méthodes dans toutes les sous-classes"...
- Voir cet article : http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.html et notamment la célèbre citation de James Gosling (le créateur de Java) : "Si vous pouviez recommencer Java à 0, que changeriez-vous ?" "J'éliminerais 'extends' (et donc l'héritage d'implémentation)."
Hello,

Julien Royer a écrit :
(...) risque de faire exploser des organes internes dont je comptais me servir encore quelques années.
C'est copyrighté, ou on peux la réutiliser en société?

Il y a juste une question qui me taraude, pourquoi tout le monde parle systématiquement de classes, alors qu'on peux faire de la POO sans (quelqu'un a dit Javascript) ?
Julien Royer a écrit :
Bonjour,

Je me suis retenu d'intervenir depuis la naissance de ce sujet


C'est dommage ! Je pense que le but du topic est justement de révéler les erreurs et certaines incompréhensions.
Ce sujet méritait de voir le jour.

Julien Royer a écrit :

Voici tout de même quelques pistes :

- Il existe deux modes d'héritage : l'héritage d'interface et l'héritage d'implémentation. Contrairement à ce qui est quasiment systématiquement appris aux débutants, le plus intéressant est l'héritage d'interface car il permet de découpler efficacement les composants logiciels. L'héritage d'implémentation couple fortement la classe mère et les classes dérivées, et les personnes qui ont quelques années d'expérience en POO sentent bien qu'il y a là quelque chose de malsain ; cette sensation est très proche de celle engendrée par la vue d'une variable globale.
- En ce qui concerne la factorisation de code, la composition permet de remplacer avantageusement l'héritage d'implémentation ; pas la peine de &quot;redéfinir les méthodes dans toutes les sous-classes&quot;...
- Voir cet article : http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.html et notamment la célèbre citation de James Gosling (le créateur de Java) : &quot;Si vous pouviez recommencer Java à 0, que changeriez-vous ?&quot; &quot;J'éliminerais 'extends' (et donc l'héritage d'implémentation).&quot;


Comme tu l'as dit : Contrairement à ce qui est quasiment systématiquement appris aux débutants. <----- VRAI

Merci l'article était très intéressant et très vrai, et me permets d'aller plus loin dans ma démarche.
Bah moi je vais répondre simplement : parce que j'en vois pas l'intérêt d'une part et d'une autre parce que migrer 2 Mo de code de procédural à POO c'est long et j'ai franchement autre chose à faire de mes 8 heures de boulot...

Après, j'ai tenté la POO, j'ai même tenté de démarrer par là à vrai dire... et j'ai vite, très vite oublié. Je me serais acharnée sans doute sur des projets petits, mais sur un gros je trouve ça ingérable.

Alors l'intérêt qu'on me sort :
concision :
--- je vois pas en quoi inventaire>detruire('id') est plus concis que del_objet($id).
--- Je vois pas en quoi : 
include_once("carac_perso.php");include_once("carac_pnj.php");
$degat=$pj['force']-$pnj['end'];


est plus long à utiliser et moins compréhensible que :

include_once("class_personnage.php");
var pj = new pj($idPj);
var pnj = new pnj($id_def);
$degat=$pj->force - $pnj->end;


(voire pire, les PNJ et les PJ ayant des trucs en commun, on devrait avoir une classe "personnage" au-dessus de ces deux-là ^^)

Modularité :
Ouais, bah mon tchat, j'ai trois fichiers php à transférer (1 pour l'affichage "tchat_aff.php", 1 pour la gestion des données "tchat_insert.php", 1 pour le jquery "tchat.js"), une structure de table à créer et une ligne "<?php include_once ('tchat.php'); ?>" à insérer là où je veux dans l'html... Je vois pas en quoi la POO pourrait optimiser mon travail...

Maintenance :
à partir du moment où on use des fonctions perso, je vois vraiment pas ce que ça apporte de plus... (ça fait 7 ans que je maintiens et ajoute des modules à un véritable programme en php ^^)


Après, je ne doute pas une seule seconde avoir loupé un truc, si j'en crois tous les pros qui me disent que mon système est merdique... mais à vrai dire pour l'instant, j'ai pas encore capté quoi... (et je vous assure que je fais des efforts, j'ai déjà lu une quinzaine de topics dans ce genre + des tutoriels en tout genre...)


edit : pour ce qui est du MVC, j'ai pas attendu de passer en POO et je vois à nouveau pas en quoi la POO pourrait m'y aider Smiley ohwell
Modifié par Lothindil (08 Aug 2012 - 17:29)
Pages :
Sujet clos
Aller à