Community « Le forum « To be integrated «
Définition d'une entité mère aux sections, articles, etc...
Ces classes implémentent certes des fonctionnalités différentes, mais elles possèdent une logique très proche qui se retrouve dans les différents scripts (les fonctions php sont souvent de même nom et très proches au niveau programmation).
C'est pourquoi je propose de définir une classe "Entity" qui serait étendue par les classes Sections, Articles, etc et contiendrait les fonctions communes.
Il faudra dans un premier temps lister les classes susceptibles d'hériter de cette Entity, la liste des fonctions communes et des fonctions spécifiques à chaque sous-classe.
Et ensuite adapter les scripts en conséquence.
Un boulot pas trop difficile en fait.
| GnapZ from Caribbean 2970 posts |
Je me demande si les classes intéressées ne seraient pas les mêmes que celles de Choix de l'éditeur à utiliser pour l'article.. En fait, si ces dossiers ont tous un edit.php, c'est qu'ils sont tous concernés par des fonctions communes du genre: Voir, Imprimer, Créer, Modifier, Supprimer ... pour les principales, non ? Et puis la liste des fonctions n'est pas dans chaque script de la Phpdoc ? |
| Tof from Grenoble-Chambery 545 posts |
Il n'y a pas que le edit.php, je pensais surtout aux classes Sections, Articles, etc et leurs lots de fonctions get, list_selected, etc.. Quand on veut ajouter de la fonctionnalité à yacs (multi-langue par exemple) cela fait beaucoup de code source identique à modifier. De plus, factoriser le code permettrait de plus simplement ajouter de nouvelles fonctions (gestions de droits par exemple). ----- Tof |
Bernard from nearby-an-airport Associate, 6995 posts |
Tof : ton raisonnement est juste, on reconnait bien là le développeur chevronné que tu es ... Attention toutefois au côté obscur de la programmation objet, qui peut complexifier les choses très rapidement. Mais sur le fond, ta proposition conforte ce qui est déjà fait au cas par cas, en mode "dent de scie". En gros, l'idée est de se cantonner à du code simple et complet dans les scripts, quitte à accepter les redondances. C'est la phase montante de la dent de scie, qui voit les scripts grossir et s'empâter. A un certain point, la redondance de code devient insupportable et l'introduction d'une classe de généralisation permet de rationaliser tout ça en centralisant le code actif en un seul endroit. C'est la phase descendante de la dent de scie, qui voit les scripts retrouver leur taille fine de leur jeunesse. D'ailleurs, c'est comme ça qu'ont été introduits la plupart des scripts placés dans le répertoire shared et chargés dans shared/global.php, si je ne m'abuse.Je supporte donc totalement ton initiative, à partir du moment où "l'on attend que ça gratte" avant d'introduire de l'objet. Comme ça, on est sûr d'en avoir besoin, de l'objet. Alors, comme manifestement ça te démange, n'hésite surtout pas, tes propositions sont les bienvenues... |
Edit
Delete
