5160 sujets

Le Bar du forum

Pages :
Voilà, je me suis enfin décidée à lancer une question qui me turlupine depuis quelques temps déjà...

Je vous entends parler de POO, je sais ce que l'abréviation veut dire, mais sans plus (ou presque).

Associé à ce sujet, je vois de nombreuses remarques sur le procédural (comme quoi ça se fait pas, qu'il faut être rétrograde,...). J'ai donc fini par aller fouiller d'un peu plus près le POO... et euh... Je le trouve particulièrement indigeste et je vois pas l'intérêt. Sans doute est-ce parce que j'y capte rien...

En gros, c'est quoi l'avantage du POO ? En quoi coder en procédural est mauvais ? Qu'est-ce que ça apporte ?

Perso, à l'heure actuelle, ce que j'en ai vu c'est dans le PHP... et j'ai l'impression qu'à part avoir des variables à rallonge, et avoir des fonctions qui chargent 3000 trucs du mysql bah ça n'apporte rien. (à part une syntaxe que je trouve moins claire et moins intuitive).


Bref, c'est pas du trollage, mais une vraie interrogation...
Modifié par Lothindil (16 Nov 2011 - 13:01)
Désolé pour ma réponse courte,

Mais la POO devient évident au fil des années d'expérience de programmation, pour ma part c'était complètement abstrait au départ (je n'y comprenais absolument rien) mais maintenant c'est quelque chose de naturel et d'évident.

C'est une habitude de travail qu'on acquis naturellement à force de pratiquer la programmation je dirais..

Désolé pour ma réponse courte et abstraite ^^
Question comme ça: tu fais un petit peu de programmation PHP, ou tu développes des applications web complètes en PHP?

Pour des scripts simples, j'imagine que tu n'as pas spécialement besoin de travailler avec des classes. Pour des applications plus complexes, bah tu peux toujours faire sans mais c'est se priver d'outils efficaces.
Lothindil a écrit :

Je vous entends parler de POO, je sais ce que l'abréviation veut dire, mais sans plus (ou presque).


Disons que la programmation procédurale est plus proche du langage machine. Tes données sont des variables et tu les manipules avec des fonctions.

En programmation orienté objet on est plus proche d'un mode de pensé naturelle : un objet est défini par ses propriétés. Ex : un chien (l'objet) est un animal de la famille des canidés qui a 4 pattes et qui peut manger, dormir.

Lothindil a écrit :

Associé à ce sujet, je vois de nombreuses remarques sur le procédural (comme quoi ça se fait pas, qu'il faut être rétrograde,...). J'ai donc fini par aller fouiller d'un peu plus près le POO... et euh... Je le trouve particulièrement indigeste et je vois pas l'intérêt. Sans doute est-ce parce que j'y capte rien...


Peut être que tu regardes des exemples trop complexes par rapport à ce que tu fais actuellement en procédural.

Pour l'exemple de l'objet chien :

$medor = new Chien();

$medor->manger($nourriture);
echo $medor->estIlAffame(); // Affiche : Médor n'a plus faim.

$medor->dormir(4); // il va dormir 4 heures
echo $medor->estIlEveille(); // Affiche : Médor dort encore.

Lothindil a écrit :

En gros, c'est quoi l'avantage du POO ? En quoi coder en procédural est mauvais ? Qu'est-ce que ça apporte ?


L'objet permet plus de rigueur, et une meilleure structuration des données, une meilleure réutilisation du code d'un projet à l'autre et permet d'éviter le code redondant (copier/coller puis modif à l'arrache).

En fin de compte c'est moins le bordel, ça fait gagner du temps et ça évite de passer son temps à recoder les mêmes choses.

Lothindil a écrit :

Perso, à l'heure actuelle, ce que j'en ai vu c'est dans le PHP... et j'ai l'impression qu'à part avoir des variables à rallonge, et avoir des fonctions qui chargent 3000 trucs du mysql bah ça n'apporte rien. (à part une syntaxe que je trouve moins claire et moins intuitive).


Pas compris et je vois pas non plus le rapport avec MySQL. Smiley biggol
Au sujet de MySQL et de PHP: ne pas confondre programmation orientée objet et utilisation d'un ORM.
fvsch a écrit :
Question comme ça: tu fais un petit peu de programmation PHP, ou tu développes des applications web complètes en PHP?

Pour des scripts simples, j'imagine que tu n'as pas spécialement besoin de travailler avec des classes. Pour des applications plus complexes, bah tu peux toujours faire sans mais c'est se priver d'outils efficaces.

J'ai développé un jeu complet en PHP/MySQL ^^ (qui est 100% fonctionnel, mais 100% codé en procédural)

Et j'ai plutôt l'impression que les exemples sont beaucoup trop simples par rapport à ma problématique qui est nettement plus complexe ou

Je vais prendre un exemple banal sur mon site qui, je l'espère correspond à un objet, et va me permettre de développer un peu mon problème MySQL / POO : prenons un objet assez complexe et complet : "personnage joueur" (alias PJ). Un personnage joueur est défini par :
- des données générales (id, nom, classe, race, avatar)
- des renseignements qui s'afficheront sur la carte (skin, coordonnées)
- des caractéristiques (force, magie, endurance, maîtrises, esquives, PV, PA, PT, PM)
- des possessions (objets et compétences)
- des équipements (objet ayant une place définie)

Et quelques autres choses dans le même genre. Le tout jouant sur 16 tables MySQL.

Si j'ai bien compris, l'avantage en POO c'est d'avoir dans un fichier qqpart un truc du type :

pj()
{ // la recherche mysql de toutes les données se liant au PJ
// la transformation de ces machins en variables
}


Et donc d'avoir dans mon fichier de travail, quelque chose du genre :

$lothindil = new pj($idPj);

Et donc si j'ai besoin dans mon traitement des PA (c'est courant) de pouvoir faire :

$lothindil>PA


En procédural, j'aurais un truc du type :
$mysql=mysql_fetch_assoc(mysql_query("select PA from latable where id=$idPj"));
$pj['PA']=$mysql['PA'];



A part qu'entre temps, le programme a appelé les 15 autres tables dont j'ai aucun besoin.

Ou alors y a un truc que j'ai pas capté ? Smiley rolleyes


Edit : en fait, un des rares points positifs que j'ai vu, c'est une séparation réelle et claire entre la partie "accès aux bdd" et "business" ^^
Modifié par Lothindil (16 Nov 2011 - 17:27)
L'exemple du jeu et en particulier du personnage de jeu c'est un cas typique d'introduction à la POO (d'ailleurs c'est bizarre que tu sois pas tombé dessus parce que c'est l'exemple qui revient le plus souvent).

Avant de commencer, une bonne pratique est de séparer la logique (qu'on appelle le contrôleur), de la gestion des données (le modèle). Mais ça on peut aussi le faire en programmation procédurale, c'est juste (un peu) plus simple à faire en programmation orientée objet.

Un exemple très simpliste pour ton cas, serait (note que j'utilise du pseudo code pour tous les exemples) :

Une classe Perso qui définie les propriétés de base de tous les personnages (id, avatar, nom, hp...), et les actions communes (se déplacer, recevoir un coup).

Des classes enfants qui héritent de la classe Perso, par exemple la classe Magicien ajoute la propriété point de magie et l'action lancer un sort.

Ce qui donne :


Class Perso
{
$id;
$avatar;
$nom;
$hp;
$coordonnees;

__construct($id = NULL)
{
// si $id = NULL on crée un nouveau perso
// sinon on demande au modèle de charger le perso existant
}

function deplacement($direction, $distance)
{
// traitement sur $this->coordonnees
}

recevoir_un_coup($puissance)
{
// traitement sur $this->hp
}

sauve()
{
// demande au modèle de sauver le personnage en base de données
// si $this->id est NULL on crée un nouveau perso en BDD, sinon on met à jour l'ancien
}
}


La magicien :


Class Magicien extends Perso
{
$magie;

function lancer_un_sort($sort)
{
// lance sort et réduit point de magie
}
}


Ensuite tu as tes modèles qui s'occupent des opérations de lectures, écritures, effacement et mise à jour.

Un modèle de base avec les fonctions "bas niveaux"


Model {

create($champs, $valeurs)
{
// insert une entrée dans la bdd
}

read($id, $champs)
{
// lit une ligne de la table
}

update($id, $champs, $valeurs)
{
// met à jour une ligne de la bdd
}

delete($id)
{
// efface une ligne de la bdd
}
}


Éventuellement tu as un modèle spécifique à ton contrôleur mais dans le cas où il n'utilise que les fonctions de bases ce n'est pas obligatoire et tu passes par le modèle générique.

Voilà en gros pour le principe. Et à l'utilisation ça donnera :


$roger = new Magicien(123); // charge Roger
$roger->deplacement(1, 3);
$roger->lancer_un_sort('pokemon');
$roger->sauve(); // met à jour roger


Ou encore :


$marcel = new Guerrier() // nouveau perso
$marcel->nom = 'Marcel';
$marcel->hp = 3;
...
$marcel->sauve(); // on sauve le nouveau perso


Lothindil a écrit :

En procédural, j'aurais un truc du type :
$mysql=mysql_fetch_assoc(mysql_query("select PA from latable where id=$idPj"));
$pj['PA']=$mysql['PA'];


Ça c'est plutôt de la programmation séquentielle (ou spaghetti).

En procédurale tu aurais plutôt :


Dans ton fichier fonctions MySQL :

function lit_caracteristique_joueur($connexion, $id, $caracteristique)
{
 $mysql=mysql_fetch_assoc(mysql_query("select $carateristique from perso where id=$id");
 return = $mysql[$caracteristique];
}


et dans ton code :


$pa = lit_caracteristique_joueur($connexion, 123, 'PA');


Lothindil a écrit :

A part qu'entre temps, le programme a appelé les 15 autres tables dont j'ai aucun besoin.

Ou alors y a un truc que j'ai pas capté ? Smiley rolleyes


J'ai pas du tout compris l'histoire de charger les 15 autres tables.

Lothindil a écrit :

Edit : en fait, un des rares points positifs que j'ai vu, c'est une séparation réelle et claire entre la partie "accès aux bdd" et "business" ^^


Ça c'est conseillé aussi en programmation procédurale, et pas reversé à la POO.
Modifié par jb_gfx (16 Nov 2011 - 19:01)
Pour expliquer mes 15 tables, je vais faire simple avec 5 tables :

Class PJ ($idPj)
{
$requete = "select * 
     from pj_global 
     left join pj_carte on pjcarte.id=pj_global.id
     left join pj_carac on pjcarac.id=pj_global.id
     left join pj_divinite on pj_divinite=pj_global.id
     left join pj_equip on pj_equip=pj_global.id
where pj_global.id=".$idPj."";
$mysql=mysql_fetch_assoc(mysql_query($requete)); 
$nom=$mysql['nom'];
$classe=$mysql['classe'];
$race=$mysql['race'];
$avatar=$mysql['avatar'];
// bref, je vous passe les 30 autres données que j'ai à rajouter derrière
}


$lothindil = new PJ($idPj);

Pour récupérer $lothindil-> PA; j'ai dû lancer ma fonction et donc charger 5 tables Mysql...

Dans mon code spaghetti (j'adopte le terme, j'aime bien faire de la popote Smiley murf ), j'aurais fait 1 seul appel.

Tout ce que j'avais lu, me disais de charger le moins de variables possibles, ou pour être précis d'aller chercher dans la table uniquement les données dont j'ai besoin et pas toutes les variables.



Et pour les models de base... euh c'est méga-coûteux en ressources SQL ça, non ? Enfin, je sais pas, mais il me paraît logique quasiment tout le temps de regrouper au maximum la moindre requête, surtout sur le SQL. (pour les update, j'update la majorité du temps 4 ou 5 champs à la fois dans une même table Smiley murf )


Pour les fonctions de classes... je les utilise dans mon code spaghetti Smiley biggol , à part qu'elles sont pas liées à des objets... J'ai par exemple une fonction "deplacement($x1,$y1,$map1,$x2,$y2,$map2)" qui se charge des mouvements (vu que j'ai plusieurs possibilités de mouvements assez différent dans l'action d'origine, mais se gérant de la même manière); idem pour la mort ou l'ajout ou la suppression d'objet dans l'inventaire.
Quel est alors l'avantage du POO sur mon chtit code spaghetti ? Smiley biggrin



(d'après ce que j'ai pu lire, un des avantages c'est de pouvoir récupérer des scripts sur plusieurs projets; mais dans mon cas, je n'ai -et j'ai pas prévu à court ou moyen terme- d'avoir un autre projet ^^)
Modifié par Lothindil (16 Nov 2011 - 22:23)
En réponse au message ci-dessus qui disait :

Lothindil a écrit :
Bref, c'est pas du trollage, mais une vraie interrogation...


Je confirme que c'est du pur troll de base. Bref, merci de m'avoir fait perdre mon temps.
Modifié par jb_gfx (16 Nov 2011 - 22:35)
C'est pas parce que tu fais de la POO que tu est obligé d'écrire une classe monolithique qui bouffe inutilement de la mémoire et des requêtes SQL (ou encore des lectures/écriture disque), hein.

Je connais pas grand chose en programmation (bah ouais...), mais il me semble que faire toutes les requêtes MySQL possibles et imaginables au moment où tu instancie ton objet (plutôt qu'au moment où tu accèdes à une propriété particulière de l'objet), c'est un peu une connerie.

Il me semble qu'on va plutôt écrire des méthodes dès qu'il s'agit de récupérer des données avec une action consommatrice de CPU, I/O ou réseau. Pas tout faire d'un coup et stocker dans des propriétés.

En gros tu es en train de nous dire que du procédural bien fait c'est mieux que de la POO pas du tout maitrisée. No shit, Sherlock. ^^
Je m'attendais à ce qu'on arrive là... Smiley decu Je vous assure que c'est pas du trollage. Je parviens pas à capter ce que m'apporterais la POO par rapport à mon séquentiel (que je pensais être du procédural, j'ignorais qu'il existait une troisième forme de programmation).

Pour l'instant, je vois que :

1) ça me permet de séparer totalement la partie "accès à la base de données" (que je dois mettre dans mes classes) de mon business. Quand j'entends séparer totalement, c'est dans des fichiers différents. Je fais déjà une séparation dans mon code séquentiel/spaghetti, j'ai des parties différentes dans chacun de mes fichiers et d'ici peu, je vais pouvoir séparer la partie "affichage html" de la partie PHP.
2) ça me permettrait d'avoir un code plus clair si un autre développeur devrait y toucher (il est certain que "$attaquant>touche" est plus clair que "$att_touche"). Cette partie m'intéresse à moitié, dans le sens où j'ai pas prévu à court ou à moyen terme de transmettre mon code; mais ça me permettrait d'avoir, pour moi un code plus clair que je pourrais relire plus facilement.
3) ça me permettrait de changer le nom d'un champ de table plus facilement (en devant changer juste dans la classe au lieu de retrouver dans tous mes fichiers qu'est-ce qui fait quoi)
4) ça permet d'avoir des fonctions à transmettre d'un projet à l'autre (ça, ça ne me concerne pas, je n'ai qu'un seul projet à court, moyen et long terme)
5) utilisation de fonction liée à des objets. (qui pour autant que j'ai pu les comprendre sont similaires à ce que j'utilise déjà)


Mais :
1) y en a pour des heures de boulot pour modifier le code pour l'adapter au POO (est-ce que le séquentiel et la POO peuvent cohabiter le temps du changement ?)
2) Il me faut prendre des nouvelles habitudes et apprendre de nouvelles syntaxes (les ":", "?","__construct",...)
3) soit on m'a appris des c*nneries coté optimisation mysql (le fait qu'il faille réduire au maximum le nombre de requêtes, le nombre de tables appelées, qu'il faille limiter les champs appelés dans le select au strict minimum,...), soit j'ai pas tout capter sur comment construire mes objets sur base des données issues de mes tables (c'est qui est tout à fait possible), soit la POO est plus coûteuse en terme de SQL.


Actuellement, je me retrouve avec 3 points négatifs qui pèsent lourds (le temps va me devenir précieux pour tout ce qui touche à mon code, ayant possiblement un boulot d'ici peu de temps dans mon domaine d'origine)... et finalement seul le point 3) a un réel avantage pour moi que ce soit à court ou moyen terme (le point 2 pourrait s'ajouter à long terme).


Bref, à lire ce forum, la POO semble être indispensable, un outil d'avenir, la seule manière correcte de coder un site... Et j'essaye de comprendre en quoi ma manière de faire est moins bonne ou moins adaptée à ma situation... si elle l'est. (dans un sens plus général, je veux bien vous croire, vous en connaissez certainement bien plus que moi)
Je suis juste pas du genre à adopter une méthode "parce que tout le monde fait comme ça maintenant" et j'aimerais être certaine qu'elle conviendrait à mon cas avant de m'y plonger.

(j'ai réussi à me plonger dans le JQuery parce que ça facilitait certaines choses, je suis passée à l'Ajax après avoir pesé le pour et le contre aussi d'ailleurs).


a écrit :
En gros tu es en train de nous dire que du procédural bien fait c'est mieux que de la POO pas du tout maitrisée. No shit, Sherlock. ^^
oui et non...
Je me demande si la POO moyennement maîtrisé (en gros basée sur des tutoriels et des sources d'informations parfois douteuses) peut être intéressante par rapport à un procédural/séquentiel bien maîtrisé (genre 4 ans que je travaille avec) et ce que pourrait à moyen ou à long terme m'apporter la POO moyennement maîtrisée par rapport à mon procédural actuel.

En gros, est-ce que pour quelqu'un pour qui la programmation n'est qu'un loisir, mais qui satisfait à des besoins de clients (même s'ils payent pas Smiley langue ), la POO a vraiment un intérêt; ou le procédural/séquentiel peut être tout à fait viable dans ce type de projet à moyen ou à long terme, sachant que j'en suis et j'en serais toujours l'unique programmatrice.


edit : Forcément à l'heure actuelle, ma POO ressemble à rien, c'est certain. Je m'y suis jamais véritablement penchée et à dire vrai, il y a encore quelques semaines j'ignorais ce que ça voulait dire. Smiley sweatdrop
Et je pense que pas mal de doutes ou de craintes viennent du fait que je comprenne pas le fonctionnement et les subtilités. Mais que j'aimerais lever les craintes AVANT de m'y pencher (ou plutôt j'aimerais être certaine que je vais y gagner en m'y penchant).
Modifié par Lothindil (16 Nov 2011 - 23:19)
fvsch a écrit :
C'est pas parce que tu fais de la POO que tu est obligé d'écrire une classe monolithique qui bouffe inutilement de la mémoire et des requêtes SQL (ou encore des lectures/écriture disque), hein.


Rasmus Lerdorf (créateur de PHP) parle du modèle MVC (c'était en 2006) :
http://toys.lerdorf.com/archives/38-The-no-framework-PHP-MVC-framework.html

fvsch a écrit :

Je connais pas grand chose en programmation (bah ouais...), mais il me semble que faire toutes les requêtes MySQL possibles et imaginables au moment où tu instancie ton objet (plutôt qu'au moment où tu accèdes à une propriété particulière de l'objet), c'est un peu une connerie.


C'est juste une question de logique et de bon sens, non ?

fvsch a écrit :

Il me semble qu'on va plutôt écrire des méthodes dès qu'il s'agit de récupérer des données avec une action consommatrice de CPU, I/O ou réseau. Pas tout faire d'un coup et stocker dans des propriétés.


Même pas besoin d'argumenter.

fvsch a écrit :

En gros tu es en train de nous dire que du procédural bien fait c'est mieux que de la POO pas du tout maitrisée. No shit, Sherlock. ^^


Que rajouter ?

Florent, non programmeur qui parle de programmation : +1000
Modifié par jb_gfx (16 Nov 2011 - 23:23)
Lothindil a écrit :
Je m'attendais à ce qu'on arrive là... Smiley decu Je vous assure que c'est pas du trollage. Je parviens pas à capter ce que m'apporterais la POO par rapport à mon séquentiel (que je pensais être du procédural, j'ignorais qu'il existait une troisième forme de programmation).


C'est la forme originelle de programmation (BASIC powa).

Lothindil a écrit :

1) ça me permet de séparer totalement la partie "accès à la base de données" (que je dois mettre dans mes classes) de mon business. Quand j'entends séparer totalement, c'est dans des fichiers différents. Je fais déjà une séparation dans mon code séquentiel/spaghetti, j'ai des parties différentes dans chacun de mes fichiers et d'ici peu, je vais pouvoir séparer la partie "affichage html" de la partie PHP.


Rien compris, je vais relire demain.

Lothindil a écrit :

2) ça me permettrait d'avoir un code plus clair si un autre développeur devrait y toucher (il est certain que "$attaquant>touche" est plus clair que "$att_touche"). Cette partie m'intéresse à moitié, dans le sens où j'ai pas prévu à court ou à moyen terme de transmettre mon code; mais ça me permettrait d'avoir, pour moi un code plus clair que je pourrais relire plus facilement.


+1

Lothindil a écrit :

3) ça me permettrait de changer le nom d'un champ de table plus facilement (en devant changer juste dans la classe au lieu de retrouver dans tous mes fichiers qu'est-ce qui fait quoi)


Tu peux déjà le faire en procédurale, mais oui.

Lothindil a écrit :

4) ça permet d'avoir des fonctions à transmettre d'un projet à l'autre (ça, ça ne me concerne pas, je n'ai qu'un seul projet à court, moyen et long terme)


Pas de commentaire

Lothindil a écrit :

5) utilisation de fonction liée à des objets. (qui pour autant que j'ai pu les comprendre sont similaires à ce que j'utilise déjà)


Fonctions d'un objet = méthode.


Lothindil a écrit :

Mais :
1) y en a pour des heures de boulot pour modifier le code pour l'adapter au POO (est-ce que le séquentiel et la POO peuvent cohabiter le temps du changement ?)


Oui en PHP c'est possible. Exemple : Worpdress qui gère sa transition du modèle procédural au modèle objet depuis 2 versions majeures.


Lothindil a écrit :

2) Il me faut prendre des nouvelles habitudes et apprendre de nouvelles syntaxes (les ":", "?","__construct",...)


La syntaxe ça reste le plus facile à apprendre dans un langage de programmation.


Lothindil a écrit :

3) soit on m'a appris des c*nneries coté optimisation mysql (le fait qu'il faille réduire au maximum le nombre de requêtes, le nombre de tables appelées, qu'il faille limiter les champs appelés dans le select au strict minimum,...), soit j'ai pas tout capter sur comment construire mes objets sur base des données issues de mes tables (c'est qui est tout à fait possible), soit la POO est plus coûteuse en terme de SQL.


Ça fait 3 ou 4 fois que je le répète mais je ne vois toujours pas le rapport entre SQL et POO. Ça n'a absolument rien à voir.

Et pour la suite je ne répond pas ce soir, je suis un peu gavé.
Modifié par jb_gfx (16 Nov 2011 - 23:43)
Un grand merci pour ton lien, c'est le genre de renseignements et d'astuces/techniques dont je manquais pour résoudre un de mes soucis vis-à-vis de la POO (et possiblement du procédural, j'en sais rien). A aucun moment, j'aurais eu l'idée de créer un fichier par table et donc pour moi, avec la POO, je me retrouvais forcément à devoir tout charger d'un coup. Bon sur ce point-là, j'ai l'impression d'avoir quand même loupé une information ou une méthode de travail d'une manière ou d'une autre (mais ça semble tellement logique pour tout le monde que c'est peut-être mon cerveau qui marche bizarre).

Idem pour les fonctions de bas niveaux... j'avais jamais pensé à passer un array comme argument d'une fonction. Effectivement, avec cette technique-là, ma remarque était totalement stupide.

Et si la syntaxe est le plus simple à apprendre, les habitudes sont nettement plus difficiles à changer, surtout quand elles sont solidement ancrées. Et le mieux pour les modifier, c'est de savoir la raison du changement. Smiley cligne


Donc si j'ai bien compris, il n'y a aucune différence entre mes fonctions (typiquement celle d'ajout ou de suppression d'un objet dans l'inventaire qui recoupe énormément d'autres choses) et les méthodes ? (et en pratique, rien ne m'empêcherait de transformer mes fonctions qui marchent très bien en méthode si je venais à passer en orienté objet)

Pour le fait que les 2 puissent marcher en //, ça m'arrange parce que c'est pas une petite application mon jeu Smiley biggol .



Pour ce qui est des méthodes, je les applique peut-être involontairement d'une manière correcte. (pour l'instant j'utilise mes fonctions surtout quand c'est des points qui reviennent plusieurs fois dans mes codes, dans des fichiers et des situations différentes; la suppression d'un objet de l'inventaire est assez typique). Mais j'avoue avoir aucune notion du coût autre que MySQL et légèrement du coût d'un algorithme. Smiley confused
Lothindil a écrit :
soit j'ai pas tout capter sur comment construire mes objets sur base des données issues de mes tables (c'est qui est tout à fait possible), soit la POO est plus coûteuse en terme de SQL.

Première réponse. La POO n'implique pas de surcout en temps CPU, requêtes SQL, utilisation mémoire, occupation I/O, etc.

Je ne sais pas au juste comment fonctionne ton application, mais il est probable que si tu voulais faire la même chose en POO tu aurais plusieurs classes plutôt qu'une classe PJ monolithique, de l'héritage qui va bien (les PNJ partagent des caractéristiques avec les PJ et il y a sans doute une classe abstraite à écrire pour ces caractéristiques communes), et une programmation un peu intelligente (qu'elle soit objet ou procédurale ou danseuse orientale) où tes requêtes SQL ne partent pas en vrille. En gros, quand tu instancie un objet tu as zéro requêtes SQL ou une requête unique qui part et qui récupère les infos essentielles que tu utilises tout le temps... et les autres infos sont récupérées par des méthodes qui vont bien (qui font aussi des requêtes SQL si nécessaire).

Lothindil a écrit :
Pour le fait que les 2 puissent marcher en //, ça m'arrange parce que c'est pas une petite application mon jeu Smiley biggol .

Tu as peut-être de nouvelles fonctionnalités suffisamment séparées du reste que tu pourrait développer en POO, pour tester un peu?
Là dans l'immédiat je vois pas trop l'intérêt de refaire toute ta codebase en POO.

Par contre si dans ton code existant tu as des morceaux de logique applicative qui sont dupliqués à plusieurs endroits, et que donc globalement ça manque cruellement de factorisation... tu peux bosser sur de la refactorisation sans forcément faire de la POO, comme le soulignait jb_gfx.
fvsch a écrit :

Première réponse. La POO n'implique pas de surcout en temps CPU, requêtes SQL, utilisation mémoire, occupation I/O, etc.

Je ne sais pas au juste comment fonctionne ton application, mais il est probable que si tu voulais faire la même chose en POO tu aurais plusieurs classes plutôt qu'une classe PJ monolithique, de l'héritage qui va bien (les PNJ partagent des caractéristiques avec les PJ et il y a sans doute une classe abstraite à écrire pour ces caractéristiques communes), et une programmation un peu intelligente (qu'elle soit objet ou procédurale ou danseuse orientale) où tes requêtes SQL ne partent pas en vrille. En gros, quand tu instancie un objet tu as zéro requêtes SQL ou une requête unique qui part et qui récupère les infos essentielles que tu utilises tout le temps... et les autres infos sont récupérées par des méthodes qui vont bien (qui font aussi des requêtes SQL si nécessaire).
En fouillant dans mes archives, je suis retombée sur un test de création d'objet (qui n'est plus à jour) et j'avoue qu'il me fait aussi peur que le monolithique... mais à l'inverse. Smiley confus
Je me retrouve avec des dizaines d'héritage et je pense que c'est cette conception-là qui m'avait dégoûtée car plus illisible encore... C'est le genre de truc où on se retrouve avec des variables ressemblant à ça au final :
$lothindil->personnage->joueur->caractéristiques->PA

Bref, le genre de trucs qui à vue de nez est encore moins lisible et maniable. (là aussi c'est peut-être juste ma manière de voir, mais les if qui rentrent sur 3 lignes, suis pas fan)


fvsch a écrit :
Tu as peut-être de nouvelles fonctionnalités suffisamment séparées du reste que tu pourrait développer en POO, pour tester un peu?
Là dans l'immédiat je vois pas trop l'intérêt de refaire toute ta codebase en POO.
de nouvelles, j'en ai pas de prévu dans l'immédiat, mais j'ai des fonctionnalités assez séparées pour être reprogrammées différemment.

fvsch a écrit :
Par contre si dans ton code existant tu as des morceaux de logique applicative qui sont dupliqués à plusieurs endroits, et que donc globalement ça manque cruellement de factorisation... tu peux bosser sur de la refactorisation sans forcément faire de la POO, comme le soulignait jb_gfx.
C'était ma précédente étape d'optimisation de code... faut encore que je l'achève, il doit me manquer 2 ou 3 fonctions encore ^^



*sent qu'elle va se plonger dans les bases, genre avec les notions théoriques de la POO avant de continuer à vous embêter. A l'impression au passage que son système avec "un type d'action = un fichier .php" serait peut-être à revoir... ou pas*
Modifié par Lothindil (17 Nov 2011 - 10:14)
Non mais de toute façon il fallait tout coder en Python à la base, pas avec du PHP. Smiley rolleyes

(Ah tiens c'est pas encore vendredÿ? Toutes mes confuses.)
Tiens, j'y avais pas pensé. Smiley rolleyes (remarque, on m'avait déjà proposé le java, le flash et le ruby... pourquoi pas le python Smiley ravi )


Bref, merci quand même pour vos réponses, je commence à voir les intérêts de la POO et regrette un peu de ne pas m'y être intéressée plus tôt dans le projet. (genre y a 2 ou 3 ans de ça, quand il était plus simple et plus réduits en quantité de fonctionnalité). Je capte un peu mieux pourquoi c'est "mieux" ou "plus adapté" que le procédural (et que le bon vieux code séquentiel) dans pas mal de cas...


Le fait de penser être dans du procédural est pas totalement faux, même s'il ressemble encore un peu à du bidouillage spaghetti, j'utilise pas mal de fonctions pour les gros trucs répétitifs, mais pas encore pour tout ce qui se répètent (genre les requêtes SQL).


Tout ça pour dire que oui, je vois l'intérêt de la POO maintenant (ce qui je vous assure était pas le cas y a encore 48h), mais que le rapport coût/bénéfice dans mon cas particulier (travaillant seule sur mon code, n'ayant aucun autre projet et ayant un temps fort réduit bientôt) va dans le sens de rester dans ma lignée de codage : continuer à trier mes spaghettis et de continuer ma lente progression vers le procédural. Smiley ravi

Quant au lien sur le MVC je le garde à portée de main. J'avais commencé à nettoyer mon code pour avoir mes 3 tiers de mon architecture clarifiée et séparée et il donne des pistes intéressantes pour aller un cran plus loin dans la clarté.
Modifié par Lothindil (17 Nov 2011 - 11:21)
Bonjour.
Lothindil a écrit :
$lothindil->personnage->joueur->caractéristiques->PA
Si tu en arrives à avoir ce genre de code, c'est qu'il y a un problème de conception à la base.
En théorie, tu devrait plutôt avoir
$conan = new Warrior(); $conan->pa //3 000 000 


Quelques suggestions si tu veux progresser (et si tu as le temps) :
- Apprendre la syntaxe objet de PHP (pas compliqué).
- Se former en modélisation (rien que quelques bases en UML, ça aide pas mal).
- Se faire la main sur un framework, puis aller regarder comment il est codé quand tu es à l'aise avec.
- Tester d'autres langages.
Salut,

La POO, ce n'est pas l'héritage d'implémentation, contrairement à ce que l'on apprend souvent à tort aux débutants. Il vaut mieux oublier cette notion et commencer par des concepts plus simples, moins dangereux et dont l'intérêt est plus évident, comme l'encapsulation.

L'intérêt de l'encapsulation est de garantir la cohérence d'un ensemble de données, de centraliser les traitements communs à ces données et d'en abstraire la représentation pour le code qui l'utilise.

Comme pour beaucoup de domaines de connaissance liés à l'informatique, la majorité des ressources d'apprentissage sur le Web et dans les librairies est hélas de (très) mauvaise qualité. Désolé de ne pas en citer de bons, il en existe certainement mais je ne les connais pas.
Modifié par Julien Royer (17 Nov 2011 - 12:15)
Pages :