Scinder Un Fichier De Classe, (quand il est trop gros)

Hello,

Je n'arrive plus à m'y retrouver dans certaines classes objets. des fichiers de 3000 lignes, avec 30 fonctions, c'est ingérable. Je souhaite donc scinder ces fichier en 4 ou 5 morceaux, mais là : hic.

j'ai mis les fonctions dans un fichiers à part, et je fais un include dans le corps de la classe. Mais là, je me prends un erreur. Les includes n'ont pas le droit d'être fait là.

Donc, comment scinder une classe en plusieurs fichiers ?

Si quelqu'un sait, je suis preneur.

Merci,

Nygma.

Heu 3000 lignes pour une classes, ça me parraît un peu énorme, faudrait idéalement que tu puisses diviser ta classe en plusieurs. Si c'est pas top secret, tu peux toujours mettre un lien sur le site si tu veux des avis plus pointu.

ben en fait, la taille est surtout faite par les nombreuses fonctions.

quand à éclater les grosses classes en plus petites, je préfèrerais pas. Si je peux éviter. j'ai pas spécialement envie de reprendre tout le code.

3000 lignes, c'est pour la plus grosse. La classe des persos. forcément, à raison d'une trentaine de fonctions, et de 150 variables de classes, j'arrive vite à 3000 lignes.

mais sans rire, y'a pas moyen de scinder un fichier de classe ?

Et sans rire, c'est quoi les 150 variables de ta classe, je suis curieux de le voir. Pour moi ça relève plus d'une erreur de conception qu'autre chose.
Poste donc ton fichier, qu'on voit ça, parce que là, c'est difficile de te conseiller dans le vide.

c'est dingue, ça.

"erreur de conception".

je vous demande pas de JUGER mon boulot.

je vous demande COMMENT on peut scinder un fichier de classe.

est-ce faisable, OUI, OU NON.

après, la façon dont j'arrange mon code, c'est MON problème.

Si tu veux vraiment jeter un coup d'oeil à ma conception commence donc par lire ma synthèse de conception de ma Version 4 (pas encore en ligne). tu verras, 130 pages.
puis, regarde mon modèle physique de données (pas à jour, d'ailleurs). Que tu jugeras sans doute très mal conçu aussi.
Je les avais posté ICI
(le MPD est à la fin du thread)

Quand à la conception objet, je suis en PHP4, qui n'est quand même la panacée en terme de conception objet.

enfin, pour ta gouverne, il y a pas 3 ans, je ne savais pas écrire une seule ligne de Html, et encore moins de PHP. J'ai appris tout seul, sans formation aucune. Donc, il est certain qu'un puriste comme toi flipperait en voyant mon code...

mais tu sais quoi ?

ça marche quand même.

ben ya une solution qui consiste à créer des appels d'autres classes dans ta classe principal et de coller ces classes avec certaines fonctions spécifiques dans un autre fichier.

Et tu inclues le fichier contenant tes nouvelles classes au début de ton fichier contenant ta "grosse" classe.

Enfin bon... une classe de 3000 lignes pour seulement 30 fonctions, c'est louche XD.

tu peux préciser sTP ?

Là ça reste encore un poil trop abstrait.

Merci

Nygma

Ben en admettant la chose suivante :

perso.php

ton fichier deviendrait :
coordonnees.php

et ton fichier perso.php

Enfin voilà. Certains diront que ca peut faire du trash code parce qu'il n'y a pas forcement le besoin de créer une classe Coordonnees mais si tu veux soulager ton source de ta classe principale, je pense que c'est le seul moyen qui soit "correct".

Quand Galdor dit qu'il s'agit d'un problème de conception ce n'est pas une insulte : ça veut dire que le problème n'est pas au niveau du codage ni au niveau de l'architecture mais bien au niveau de... la conception (ta da !).

Ca ne veut pas dire que tu pouvais le prévoir forcément à l'avance : le refactoring fait parti intégrante d'un projet un tant soit peu volumineux.

Bon, je vois plusieurs façons d'aborder ton problème.

1. la technique du gros feignant : trouver un IDE suffisement malin pour te permettre de manipuler de grosses classes sans se tirer une balle. C'est pas joli joli, mais c'est pas cher... sauf que je ne connais pas d'IDE pour PHP répondant correctement à ce besoin.

2. la technique du gars prévoyant : la conception est revue tout au long du projet, ce qui implique des changements quasi quotidient de la conception pour coller à la réalité du codage qui n'est JAMAIS exactement celle attendu à la conception, et donc on ne se retrouve pas avec une classe de 3000 lignes. Dans ton cas je crois que c'est mort.

NdR de mis parcours : bon, à ce stade tu dois te dire que je me fou un peu de ta gueule avec mes solutions impossibles à mettre en pratique dans ton cas. Ca m'apprendra à écrire en même temps que je réfléchis

3. la technique du découpage traditionnel : tout bêtement découper ta classe C en n classes C1, C2, ..., Cn reprenant chacune une partie des fonctionnalités. Avantage : découpage simple à faire. Inconvénient : les classes qui utilisent C vont devoir être retouchées aussi, et ça c'est souvent très chiant. D'autant que rien ne dit qu'il ne faudra pas un jour redécouper la classe Cx. Et puis je ne suis pas sûr que celà réponde au principe d'ouverture/fermeture...

4. la technique du découpage traditionnel + design pattern façade : découper ta classe C en n classes C1, C2, ..., Cn reprenant chacune une partie des fonctionnalités. Conserver la classe C avec toutes ses méthodes mais telle qu'elle utilise les classes C1, C2, ..., Cn et appelle les méthodes de ces classes (je m'exprime mal, le mieux est que tu fasses une recherche sur le design pattern façade si tu ne connais pas déjà). Avantage : pas besoin de toucher les classes qui utilisent C. Et si la classe Cx est modifié par la suite, les impacts resteront limités à C.

Bon, je ne suis pas sûr d'être clair, mais voilà la piste que j'explorerais (le point 4) si j'étais toi.

Dodo...

Tu peux mette un include dans le corps d'une fonction, qui sera comme recopié tel quel à la place du include.
Ca veut dire grosso-modo 1 fichier par fonction (même si tu n'es pas obligé de toutes les déporter ailleurs)

oki.

tarot : merci. ça revient à exploser ma classe en sous classe. (solution 3 de grouik?)

Grouik : merci pour les détails ! la solution 4 a en effet l'air sympa. (comme je le disais dans mon 2ième message, je souhaite éviter d'exploser mes classe. mais "éviter" ne veut pas dire que je ne le ferai pas.)
quand au refactoring, la Version 4 de mon jeu est le refactoring complet de la V3.5.
V3.5 => 6 - 12 mois de boulot
V4 => 20 mois de boulot

Donc, je referais peut-être une passe de refactoring pour la V5. mais bon, là, à 20h de boulot de mettre en ligne la V4, je vois mal repasser tout mon code au peigne fin.

Haiken : ouaip, j'y avais pensé, mais c'est pas trop pratique.

Bon ben je crois que j'ai ma réponse : On peut pas casser un fichier de classe.

Merci à tous

Nygma

Vu ta réaction, j'en conclus qu'il s'agit bien d'une erreur de conception.

Parce que je suis vraiment trop gentil, dégage ta classe, et introduit:

- Une factory de User, qui utilise des instances d'une DataSource (DbSource, XmlSource...) pour créer des users initialisés.
- Une classe virtuel de Renderer, qui prend des objets et les affiche à l'écran. Tu en dérives une classe UserRenderer qui s'occupe spécifiquement des users.

Et hop, tu as pas mal de classes au lieu d'une, une meilleure modularité, un bien meilleur contrôle, etc.

ps: ah ui, l'organisation, c'est ton problème, donc pourquoi tu ne cherches pas tout seul ? j'adore ça...

ps2: php4 pour de l'objet, ça s'appelle de l'inconscience, mais si ça t'amuses...

ps3: ta doc de conception au format Microsoft Word®© et compagnie, tu peux te la garder, je ne supporte pas les gens qui croient que tout le monde utiliser Windows et compagnie, on a pas inventé le pdf et le postscript pour les chiens (et pour imprimer, c'est mieux).

ps4: ya des tas de trucs qui marchent, ça n'empêche pas que ça peut être daubesque, et que le premier truc à comprendre pour s'améliorer, c'est que c'est pas en envoyant ceux qui veulent t'aider se faire voir que tu va progresser...

Allez zou, une bonne partie des gens ici présents viennent de se faire insulter de chien (quoique la notion d'insulte dans ce cas reste encore à démontrer, mais c'est un autre débat).
Mais pourquoi tant de certitude quant à tes connaissances ? Pourquoi tant d'extrêmisme ?! Qu'est-ce qui a bien pu t'arriver pour en arriver là ?!
Parle nous ! Donne nous des indices pour t'aider ! Ne reste pas dans ce cercle vicieux, il faut s'en sortir !
Je suis persuadé, en plus, que tu n'es pas incompétent.

Galdor, c'est dommage que tu sois si arrogant et agressif, parce qu'au départ j'étais d'accord avec toi : une classe de 3000 lignes, c'est une erreur de conception. Il faut repartir de 0 avec des classes génériques qui sont dérivées afin de spécialiser à chaque pas un peu plus jusqu'à arriver à la classe finale User_pourLeSiteDeNygma.

@nygma : Scinder *proprement* un fichier de classe, ce n'est pas possible, et si tu commences à bricoler tu vas dégueulasser ton code et le jour où tu voudras reprendre la conception pour coller à nos conseils, ce sera tout simplement devenu impossible !

Ensuite, Galdor qui mélange tout, mauvaise conception = cach en MSWord = suppot de microsoft = chien d'infidèle mangeur de têtes de canard à la pleine lune
Non franchement ça frise le ridicule après, tu devrais cesser cette troll-attitude, ça n'amène rien de bon. Quand on a des choses à dire, qu'on veut que les autres entendent, on met un minimum les formes
Et puis c'est quoi cette espèce de "j'me la pète avec mes termes anglais pour t'en mettre plein la vue" ? Alors qu'il a clairement exprimé le fait qu'il n'a pas une culture objet avancée. C'est juste pour te redorer le blason et ça c'est petit Ou alors pire, tu es DSI et tu aimes mettre plein de mots compliqués pour faire style ? la plupart du temps on gagne à utiliser des termes plus longs, plus clairs, vulgarisés, afin de se faire comprendre de son interlocuteur. Il a moins l'impression de se faire prendre pour un con.

Enfin, je ne vois pas en quoi faire de l'objet avec PHP4 c'est de l'inconscience ce n'est pas aussi complet, il y a une perte de performances supérieure à PHP5 (c'est sans doute ça qui te fait le traiter d'inconscient), mais ce n'est pas un bison 4 sur une étagère de porcelaine il faut utiliser les bons mots au bon endroit aussi hein...

Je sais que tu te plais à dire que c'est ta marque de fabrique d'être odieux comme ça, mais ça n'apporte rien... Tu perds en crédibilité. Je sais pertinemment que mon message s'adressera à un mur plutôt qu'à une oreille attentive, tu te penses tellement au-dessus de ça... C'est vraiment du gachis.

Edit YeDo : j'ai viré la première phrase. Le point de Goodwin a été atteint, c'est gtm qui score ! Ne soyez pas provocateur pour rien...
Edit the-gtm : bon, je l'ai cherché aussi ! Désolé ...

Les conseils de Tarot et de Grouik sont bons : il faut séparer les classes en "composants". Ces composants ne font qu'une petite partie du boulot mais qui le font sans avoir besoin d'accéder à 10.000 autres composants. De cette façon ton composant adresse (par exemple) peut être utilisé pour une personne, une société etc. Si un jour tu dois changer l'adresse (rajouter le pays par ex.), ce sera plus facile.

Il faut aussi bien séparer le "metier" de la "présentation" : le métier c'est ta classe Perso avec ses fonctions (se déplacer, manger, lancer un sort...), la présentation c'est ce qui génère le HTML.

naholyr:
Tu es bien gentil, mais tu es très doué pour interpréter à ta sauce ce que je dis...
Mon dernier post scriptum (pouah c'est pas du français, je me la pète, t'a vu...) n'a rien à voir avec le fait d'avoir une mauvaise conception, donc il n'y a strictement aucun amalgame.
Par ailleurs, je ne traite personne de chien, renseigne-toi un peu sur cette expression, tu comprendra que tu interprète très mal...

Pour les mots anglais, je ne suis pas un de ses crétins qui veulent tout traduire en français sous le fallacieux prétexte de ne pas dénaturer notre belle langue française, etc. (traduction officielle, je ne comprend pas l'anglais, donc je veux mettre du français à la place, au risque de faire marrer tout le monde avec «mèl» ou «butineur»).

PHP4 a une très mauvais gestion de l'objet, contrairement à PHP5 beaucoup plus correct de ce point de vue, tout simplement parce qu'il n'a pas été concu pour, alors que PHP5 a été developpé dans une perspective objet (mais c'est pas encore parfait, le PHP restant un langage brouillon)

Je ne suis pas odieux (tu ne m'a jamais vu odieux, j'avoue être parfois très mauvais, mais j'en arrive rarement là), je dis les choses telles qu'elles sont, c'est toujours mieux que de foutre des fleurs à chaque critique, pour ne pas que le pauvre monsieur ne se sente méprisé (et il n'y a pas de quoi, tout le monde a débuté un jour), le pauvre chou. Quand on poste sur un forum, on accepte d'être jugé par plein de gens, c'est un peu l'intérêt du truc, d'avoir pleins d'avis. Et je comprend parfaitement que s'entendre dire «Ton truc est mal conçu», quand a bossé comme un dingue, ça fait mal, mais ça arrive à tout le monde, moi le premier.

Je te remercie, j'avais un doute, j'ai tellement l'impression de ne dire que de la merde, que si tu n'étais pas là je ferais sûrement un complexe d'infériorité

En même temps, s'il souhaite coder son source en PHP4, c'est peut-être parce que son hébergeur n'a pas installé PHP5. Beaucoup ne l'ont pas fait... et il n'a peut-être pas envie de changer d'hébergeur "rien que pour ça".

Alors discréditer l'auteur de ce sujet parce qu'il fait des classes objets en PHP4, ca me parait mal venu.

Maintenant oui, j'ai pas regardé la conception de son jeu, mais il peut aussi penser à utiliser l'héritage.

Ce n'est pas tant la forme qui compte (quelle importance s'il y a du fond ?) que l'aspect éducatif des contributions selon moi.

Si l'on veut qu'une contribution serve à plusieurs lecteurs, éventuellement de compétences différentes sur le sujet, c'est le cheminement vers la solution proposée (technique dans le cas présent) qui est le plus intéressant.

Ainsi j'aurais pu me contenter dans ma précédente intervention de : "Problématique classique, solution classique : design pattern façade !". Mais quel intérêt ?

D'ailleurs nygma (edit 11/09 21:23) (il me corrigera si je me trompe) est plus intéressé par la démarche que par la solution brute puisqu'il va peut-être dans un premier temps opter pour une solution moins "jolie" mais plus pragmatique (selon son contexte). Mieux vaut donc selon moi créer une réflexion sur une piste de solution possible que de pointer la solution de manière lapidaire (même si c'est celle que je mettrais en place et préconiserais si j'étais directement concerné).

Question d'approche sans doute.

ouh la....

ça part en vrille ce topic.

en fait, c'est le terme 'erreur' de conception qui m'a fait partir au quart de tour. J'invente la conception 'infrmatique'au fur et à mesure que je fais le jeu, au fur et à mesure de mes besoins. il y a 8 mois, le jeu n'avait même pas de classes. je faisait tout ou presque en fonctions de base.

La réaction initiale de Nambew, avec son "Heu 3000 lignes pour une classes, ça me parraît un peu énorme" a suffit pour me faire comprendre que j'allais dans le tas avec mes grosses classes.

Il a fallut que Galdor rentre dans le tas à pieds joints. (ça m'a légèrement exaspéré, puisque le message 'subliminal' et politiquement correct de Nambew était déjà passé. Pas la peine d'en remettre une couche)

m'enfin, c'est une question de caractère. j'ai le mien aussi, et je ne suis pas toujours facile. donc je passe sur la réaction allergique à mes propos.
(Ps : j'ai rien pour pdfer un word, chez moi, je ne peux le faire qu'au taff. Mais du taff, je ne peux pas ftper mon site.... sinon, tu pourras remarquer que les romans que j'ai écrit sont en pdf sur mon site.)

enfin, sur le fond, des sous-classes de la classe perso, j'en ai déjà un certain nombre. je n'ai juste pas le temps ACTUELLEMENT de pousser la réorganisation à terme. ça fait déjà 18 mois que les joueurs attendent la version suivante, donc, je vais sortir une version qui marche. point.

ensuite, quand le jeu sera stabilisé en production, je réorganiserai le code pour l'alléger.

Donc, comme dis précédemment, j'ai eu les infos dont j'avais besoin, Merci à tous.

Avant de se lancer dans un grand refactor de tes classes, un point important (vital ?) est de mettre en place des tests unitaires.

Par exemple supposons que ta classe perso a un attribut arme-dans-la-main-droite et un arme-dans-la-main-gauche et qu'il soit interdit d'avoir un arc dans chaque main. Tu peux faire un test qui vérifie que c'est bien interdit.
Ensuite si tu refactore ta classe perso pour avoir un champs de type "équipement", le test unitaire devra continuer à marcher, sinon tu as introduit un bug !

A chaque fois que tu détectes un bug (ou qu'un joueur en signale un), avant de le résoudre tu crée un test qui met le bug en évidence (le test doit foirer donc !). Ensuite tu résouds le bug et tu vois que ton test est vérifié.
De cette manière tu as une "bibliothéque" de tests qui s'enrichit au fur et à mesure. Lorsque tu fais des évolutions cela te permet de limiter les risques de bug.

(j'avais raison, je m'adressais à un mur)

Concernant les tests unitaires, à cet usage il y a une très belle librairie PHP, SimpleTest : http://www.onpk.net/php/simpletest/

whalou...

compliqué ce truc, Naholyr...

je suppose que les tests unitaires sont un truc que les vrais informaticiens connaissent.
Je pense qu'une explication de vive voix vaudra mille tutoriaux. Je verrai ça avec un pote informaticien, parce que là, même après 15 min de lecture d'un tutoriel qui a l'air bien fait, je pige toujours pas. Je dois louper le contexte.

En fait, ce que je pige pas, c'est que si tu changes ta structure pour faire du refactoring, tu es obligé de modifier aussi le code de test tests unitaires ? non ?
du coup, le bug que tu introduit par erreur dans la vérif 'pas deux arcs en main', tu l'introduit aussi dans ton test unitaire.

ça apporte quoi par rapport à une bonne procédure d'essai?
désolé, je suis ingé d'essai à la base...

Ma méthode de test est simple et vient directement de mon ex taff en centrale.
tester et documenter les briques élémentaire. Les connecter. Tester les sous-ensembles un par un. Tester tout ensemble depuis le début. (en l'occurence, de la création des persos à leur arrivée à haut niveau).

Bien sûr, il reste toujours quelques bugs .... mais bon....

Je te rassure, ça m'a fait le même effet au départ, on comprend au fur et à mesure que ça décante puis effectivement si tu as quelqu'un qui peut te raconter et surtout te montrer de vive voix, ce sera plus simple.

Non surtout pas, sinon c'est le symptome direct d'une erreur de conception. Le fait d'ajouter une arme à gauche ou à droite doit passer par un appel de méthode, que tu refasses le coeur de ta classe ou non, la méthode doit rester la même, et le test rester identique (les arguments peuvent légèrement changer et le test sera alors modifié, mais c'est anecdotique).

tiens naholyr, tu t'es mis à SimpleTest ?

au tout début ça parait difficile, mais c'est pas si compliqué que ça, les tests unitaires.

coté docs, il faut lire et intégrer les 3 premières de la liste, c'est suffisant pour bien commencer.

les tests unitaires sont des vérifications, du genre:
_ je crée un objet, je vérifie la valeur des membres par défaut;
_ je vérifie les données et le nombre d'enregistrement en DB avant et après avoir lancé une methode d'inscription;
_ je vérifie que la fonction de vérif de formulaire me renvoie toutes les erreurs si j'envoie des données foireuses
_ etc etc

ça n'évite pas les erreurs de conception ( _j'en fait de temps en temps_ ) mais ça a le mérite de "valider ses classes comme élément non buggué du langage". en clair, on a de nouvelles classes/fonctions "sûres" dans le langage, que l'on peut utiliser bien ou mal dans les scripts. ça réduit le champ des bugs très très fortement.

A+

Pascal

J'ai pas tout lu (parceque je suis sans doute lâche), donc désolé si je vais répéter un truc déjà dit,

mais en PHP, il existe 2 type d'inclusions:
- include
- require

La différence est que:
- require injecte le code AVANT de l'exécuter
- include exécute le code du fichier puis injecte le RÉSULTAT dans le fichier qui a le include('fichier.php');

Donc, -si je ne me trompe pas- tu pourrais prendre ceci:

/Index.php:

et faire ceci:

/Index.php:

/methodes/classPerso/abc.php:

/methodes/classPerso/dfg.php:

Si jamais je me trompe, pour une raison X ou Y, hésitez surtout pas à me le dire car je vais bientôt me lancer dans la conversion de mon moteur de jeu en P.O.O. et pour certaines de mes classes, j'ai prévu de faire ca. (dont ma classe Perso justement, qui comprendra les méthodes de toutes les action relié à un personnage possible)


Et si je me fit au commentaires de début que vous avez fait, je me dirige tout droit vers un problème de conception car les 'perso' peuvent faire toutes ces actions (ca c'est un copier coller partiel fait rapido):
attaquer
aller à la banque
aller à la bibliothèque
utiliser un casier de rangement
jetter un coup d'oeil aux environs
déplacement (libre accès / code d'accès / clef)
dépouiller un perso
donner item
donner argent
etudier
fouiller lieu
utiliser un GPS
utiliser un guichet
voir/gérer inventaire
passer un examen
parler
contacter un MJ
reparer
soigner
Utiliser telephoner *UPDATE
Utiliser Radio/CB
voir fiche perso
config perso


Mais j'ai encore de la difficulter à décider si, par exemple:
- donner un item, ca relève de la classe Item ou Perso ?
- Fouiller un lieu, classe Lieu ou Perso ?
- Parler c'est le perso, alors utiliser une radio pour parler, ca reste le perso ou c'est pour la classe Item ?