Version imprimable
Bonjour à tous.
D'après vous, y a-t-il une bonne façon de ranger les propriétés et les fonctions à l'intérieur d'une classe PHP ?
Y a t-il une logique meilleure qu'une autre pour que d'autres développeurs relisent le code facilement ? Ou une standardisation a adopter ?
Par exemple, grouper les static en fin de classe, ou les public au début et les private à la fin ? Ou par ordre alphabétique ?
Merci pour vos avis éclairés !
Il n'y a pas de règles universelles. Voici ce que je fais:
- Les constantes d'abord
- Les propriétés (ordre: private, public)
- méthodes publiques d'abord (stables, elles forment l'API de la classe, elles ne changent jamais de signature ou de retour). En général, les autres développeurs ont juste besoin de voir ces méthodes et n'ont pas à voir les méthodes privées.
- méthodes privées (instables, elles peuvent changer du jour au lendemain)
- jamais de classe mélangeant méthodes normales et statiques (et rarement des statiques, d'ailleurs)
Autres conseils:
- fais des classes simples et courtes. Ça améliore considérablement la lisibilité et la facilité à comprendre ce que fait la classe.
- Même chose pour les méthodes: simples et courtes, ne pas hésiter à extraire un morceau de code pour la transformer en méthode.
- Utilise des noms explicites pour les méthodes et les variables afin qu'on n'ait pas besoin de lire le code pour savoir ce que fait la méthode
- Ne mélange pas les termes anglais et français (du genre setFichier). Utilise l'anglais (un bon développeur doit être bon en anglais), c'est la langue universelle du développement. Dans le pire des cas, utilise le français, mais surtout ne mélange pas les deux.
- Les propriétés sont des noms (money, currency), les méthodes sont des verbes d'action (askMoney(), changeCurrency())
J'approuve la majorité de ce qu'a dit Tsilefy, cependant, il est judicieux de n'avoir qu'une classe par fichier (machins PSR4), or si tu as 50.000 classes, ça fait 50.000 chargements de fichier, c'est du PHP donc vaut mieux limiter le nombre de classe.
Attention cependant, il ne faut pas qu'une classe dépasse ses fonctions métiers, ce pour quoi elle est faite, on évite qu'une classe User affiche elle-même du HTML...
Donc, je te conseille de faire les fonctions statiques que tu as besoin, elles servent souvent à gérer (semi-)automatiquement une ou plusieurs instances de la classe, à faire une manipulation qui est propre à la classe mais qui ne requiert pas le contexte de l'instance...
Pour le reste, je suis d'accord, le standard, c'est : constantes, attributs (propriétés), méthodes d'instance (fonctions), méthodes de classes (fonctions statiques).
protected n'a pas été mentionné, c'est l'un des plus importants :-P
Mais comme une classe n'est chargée que quand elle est utilisée, le nombre de fichiers n'importe pas tant que ça. Ajoutes-y opcache qui évite de recompiler les scripts à chaque nouvelle exécution, le nombre de fichiers n'a en pratique pas d'effet sur la performance.Citation:
Envoyé par IGstaff
C'est vrai. J'utilise rarement l'héritage et choisis en priorité la composition. Mais oui, si il y a des propriétés ou méthodes protected, il faut les mettre entre public et private.Citation:
Envoyé par IGstaff
On parle ici de classes utilisées pour remplir les même fonctionnalités. Opcache permet de bien alléger la compilation mais il peut être gênant aussi, il faut bien l'utiliser.Citation:
Envoyé par Tsilefy
C'est une question de pratiques :-P J'utilise la composition avec parcimonie, mais les 2 ne s'excluent pas, quand tu fais de la composition, souvent t'as de l'héritage derrière, ou au moins une interface (pas de protected dans ce cas...).Citation:
Envoyé par Tsilefy
Je préconise l'utilisation de protected sur le private, même si c'est peu courant car on voit trop de libs ou scripts dans lesquels on doit faire un gros doublon car on n'a pas accès à un truc qui pourrait paraître évident, ça permet plus de généricité et d'adaptabilité, ça n'en fait pas cependant une règle absolue.
Bref, c'est des discussions très intéressantes mais je suis pas sûr que les forums d'entraide soient le meilleur endroit, il y a-t-il vraiment un meilleur endroit ? Les sujet de débat en prog, y'en a des milliards... :D
Bien sûr que les forums d'entraide sont indiqués pour ce genre de discussion. L'entraide ne se limite pas qu'aux petits problèmes de code, les débutants peuvent aussi apprendre énormément des discussions plus architecturales (et plus généralistes). Après, ce n'est peut-être pas le bon fil de discussion, je te le concède :-)
Comme tu le dis, j'ai une forte préférence pour les interfaces, que je préfère mille fois à l'héritage. Et si je fais de l'héritage, c'est souvent des classes abstraites. Quand aux doublons, on a les traits pour ça: conceptuellement ça n'est pas de l'héritage, c'est juste du copier-coller de code, et c'est exactement ce qu'il me faut.
Merci beaucoup pour vos réponses !
J'avais déjà la logique constantes/propriétés/fonctions bien sûr. J'ai tenté des rassembler les fonctions publiques puis les privées.
Par contre ici je me pose une question. J'ai une architecture MVC. Certaines classes de controleur se retrouvent avec plus de 1000 lignes de code. Je peux sortir les statiques dans une classe utilitaire, mais le reste sera toujours gros, rien que pour ses méthodes non statiques (publiques et privées).
J'ai en effet des traitements de données assez complexes, c'est incompressible. Diviser en plusieurs classes n'apportera pas de logique et obligera à toutes les charger à chaque traitement donc je ne vois pas l'avantage de 4 classes de 250 lignes au lieu d'1 de 1000.
J'ai aussi 1 classe pour chaque page web à gérer qui sont toutes "statiques" avec juste un héritage pour les fonctions de base de gestion de page. Est-ce gênant ? est-ce mieux d'avoir des non-statiques ?
À moins que tu aies effectivementdes besoins spécifiques (mais la majorité des gens qui pensent ça se trompent), 1.000 lignes, c'est beaucoup trop. L'objectif n'est pas d'éviter de charger les classes à chaque traitement, effectivement ça ne change rien.Citation:
Envoyé par Titum
Il ne faut pas essayer d'optimiser ton code à la place de la machine, la machine sait très bien comment optimiser le code, bien mieux que toi (et que 99,99% des utilisateurs). Il faut optimiser le code pour l'utilisateur, c'est-à-dire le rendre facile à comprendre, facile à modifier, facile à (ré)utiliser.
On peut toujours extraire du code pour en faire des méthodes et des classes, c'est une question de pratique. Est-ce que tu as un "if" dans ton code? Tout ce qui suit les accolades après ce if peuvent être déplacés dans une méthode. Est-ce que tu as des "else"? Pareil. Un "switch", un "for"? Pareil. Est-ce que tu as une partie de code qui fait un calcul spécifique (même si elle fait partie d'un ensemble de calcul?) Tou ça peut s'extraire. Une partie qui affiche un texte, qui envoie des headers, etc...? On peut les extraire.
La même chose vaut pour extraire des méthodes en classe, en les regroupant en fonction de leurs paramètres, de leurs valeurs de retour, en transformant $this->variable en $variable passé par paramètre et ensuite retourné, etc...
Si tu n'es pas sûr comment faire, regarde du côté des techniques de refactoring (elles sont les mêmes qu'on parle Java, C# ou PHP).
Avoir des non-statiques est préférable pour moi, mais ce n'est pas non plus très grave. Fais toujours au plus simple. Si dans ton cas ce sont des classes avec des méthodes statiques...Citation:
Envoyé par Titum
Merci bien pour les conseils ! Je partage tout à fait vos logiques.