Discussion :

[tdutrion]

Peut être suis-je perfectionniste, mais la question étant "Bonne pratique POO", la réponse est celle détaillée ci-dessus, même si elle semble overkill, et pour les raisons expliquées.

La question serait "Où placer les fonctions communes dans un projet PHP ?", effectivement on pourrait citer YAGNI et favoriser les statiques... Par contre il faut être assez sûr de son coup si on ne veut pas refacto le tout pas longtemps après.

Dans ton dernier exemple alassanediakite, tu dis "rien n’empêche d'enrichir l'ancienne", je suis d'accord dans une certaine mesure, mais il est plus que possible qu'un jour tu aies besoin d'une variante pour une des classes appelantes... en quel cas (et ça je l'ai vu des milliers de fois), tu ajouteras un boolean en paramètre de la méthode, etc.

Juste pour info, un paramètre boolean est aussi un code smell.

C'est toujours la même chose en fait, pseudo pragmatisme vs clean code (le clean code venant de l'experience de gens ayant fait les erreurs avant). Si je suis aussi exigeant sur la théorie, c'est parce que mon métier est de refactorer ces applications catastrophiques... Pensez vous que mes clients se sont dit au départ "ça va être la merde à long terme" ? Non, ils se sont dit "on a pas le temps pour ces conneries théoriques, on est pragmatique ici" et ont généralement une à deux personnes full time sur la résolution de bugs...

[grunk]

Pensez vous que mes clients se sont dit au départ "ça va être la merde à long terme" ? Non, ils se sont dit "on a pas le temps pour ces conneries théoriques, on est pragmatique ici

Malheureusement on est souvent conscient que ça va être la merde à long terme. Mais quand on te chiffre X jours sur quelques choses où il faudrait X*2 pour bien faire ... ba tu fais pas bien

C'est d'ailleurs pour ça que c'est souvent dans le monde pro que tu vois des trucs horrible , les contraintes de temps et de budget font souvent que les "best practice" passent à la trappe.

[Celira]

Pour revenir au sujet de départ :
Je ne suis pas fan des traits, parce que, pour moi, ça cache les dépendances, surtout si on utilises des alias. Genre dans ce code

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
use DateHelper
{
	anneeUniv as autreNom;
}
 
protected function afficherListe($arguments)
{
	$annee_univ_actuelle = $this->autreNom();
}

Si jamais on modifie anneeUniv(), bon courage pour te rendre compte que ça va impacter afficherListe Au moins, avec une méthode statique, on aura clairement l'appel à DateHelper::anneeUniv.

Après, entre statique et injection de dépendance, j'aurais tendance à gérer ça en fonction du type de fonctionnalité.

Si c'est purement technique, du genre "formater la date du format X au format Y", je vais faire une Classe statique avec des méthodes différentes pour les différents formats.

Par contre, si il y a des règles fonctionnelles, du genre "récupérer le 1er jour de la période", sachant qu'on peut avoir des règles comme "le 1er lundi du mois", "le lundi de la semaine qui contient le 1er jeudi du mois" ou "le mercredi qui suit la pleine lune", là je vais utiliser une interface avec 3 implémentations et faire de l'injection. Comme ça, si la semaine prochaine le client décide que dans telle et telle page, la période suit en fait la règle "pleine lune", j'ai juste à changer la dépendance dans ces pages et le reste continue à marcher comme avant.

Pensez vous que mes clients se sont dit au départ "ça va être la merde à long terme" ? Non, ils se sont dit "on a pas le temps pour ces conneries théoriques, on est pragmatique ici"

Malheureusement on est souvent conscient que ça va être la merde à long terme. Mais quand on te chiffre X jours sur quelques choses où il faudrait X*2 pour bien faire ... ba tu fais pas bien

On a dit les clients grunk, pas les dev Le client c'est celui qui paye et qui veut tout, tout de suite et pour pas cher. (*) Du coup, le dev code comme il peut pour que ça fonctionne dans les temps et tant pis si on prend des raccourcis.

Pour avoir bossé à la fois en projet et en maintenance, il y a des fois où, en tant que responsable de maintenance, tu as envie d'étrangler le développeur. Et là tu réalises que le développeur, c'était toi l'année précédente pendant ce fameux rush où l'équipe a fait la conception sur un post-it à l'arrache et zappé la moitié des tests parce que le client a ajouté trois fonctionnalités sans décaler la date de livraison et "parce que sinon on tiendra pas les délais"

(*) Je caricature bien sûr