Bonne pratique POO : Où placer les fonctions communes ?

Version imprimable

Voir 40 message(s) de cette discussion en une page

15/03/2018, 17h04
CinePhil

Bonne pratique POO : Où placer les fonctions communes ?

Bonjour,

En matière de bonne pratique en programmation objet, où placez-vous les fonctions utiles à plusieurs classes ?

Par exemple, j'ai une fonction qui détermine l'année scolaire en cours en fonction de la date et j'ai besoin de cette fonction dans plusieurs contrôleur de l'application que je développe, et même potentiellement dans plusieurs modules.

Serait-ce une bonne pratique de faire une classe générale Outils avec dedans les fonctions utiles à plusieurs endroits de l'application ?
Ou bien un simple fichier PHP contenant les fonction et à inclure au besoin dans le code des contrôleurs qui en ont besoin ?
15/03/2018, 22h36
CosmoKnacki

Si plusieurs classes partagent une ou plusieurs méthodes, tu peux utiliser les traits. Sinon un autre solution consiste à utiliser l'héritage, mais c'est moins souple car il faut que tes classes aient un ancêtre commun qui implémente la ou les méthodes (sans que ça devienne un non-sens total).
16/03/2018, 00h31
Nb

En terme de bonne pratique je ne sais pas trop.
Perso j'aurais mis ca dans une classe AnneeScolaire en tant que methode statique. Classe qui pourrait par ailleurs posseder des methodes non statique plus tard dans le projet (calculer les dates des trimestres..etc).
Si à aucun moment tu ne penses avoir besoins d objet AnneeScolaire alors mettre ca dans une bibliotheque de fonctions peut être aussi bien qu'une classe Outils.

Pour les traits je pense que ca dépend, ca va forcément marcher, ca dépend du contexte. Par exemple si tu as besoins de l'année courante dans une classe Eleve, mettre la fonctionnalité dans un trait et faire un use dans Eleve va marcher, mais ca n'a aucun sens car ta classe éléve va "hériter" d'un comportement qui n'a aucun lien avec elle. Pas sur d'avoir ete tres clair là :)
16/03/2018, 08h37
grunk
Citation:

Envoyé par CosmoKnacki

Si plusieurs classes partagent une ou plusieurs méthodes, tu peux utiliser les traits. Sinon un autre solution consiste à utiliser l'héritage, mais c'est moins souple car il faut que tes classes aient un ancêtre commun qui implémente la ou les méthodes (sans que ça devienne un non-sens total).

Niet pas d'héritage , sinon ça devient de l'héritage fonctionnel et c'est exactement ce qu'il faut éviter en POO.

Pour moi la bonne pratique c'est la création de ce qu'on va appeler des "helpers". Ce sont des classes le plus souvent statique qui permettent d'encapsuler les fonctions "utilitaires" qui peuvent être utilisée un peu partout mais qui n'ont pas à faire partie d'autre classe sémantiquement parlant.

Dans ton cas précis on pourrais imaginer un helper "date" dans lequel tu vas venir mettre toutes les fonctions utile :
Code:

1 2 3 4 5 6 7 class DateHelper { public static function getCurrentScolarYear() { // Ton code } }
Et partout où tu en as besoin tu peux faire :

Code:

$year = DateHelper::getCurrentScolarYear();

Si ensuite tu à besoin de fonction pour faire des actions sur les chaines de caractères tu peux faire un helper "StringHelper" ou tu vas venir mettre tout ce qui te permet de traiter tes chaines partout dans ton code.
Un exemple complet de helper sur les strings extrait de mon framework : https://github.com/grunk/Pry/blob/ma...il/Strings.php

Tu répètes ensuite l'opération pour toutes les "catégories" de fonctions (string,date ...)

Je suis étonné de voir autant de personnes proposer une statique...

Que ce soit les traits ou la statique, au moment de tester unitairement vos classes vous allez galérer...

Pour moi la vraie "bonne pratique" dans ce cas est l'injection de dépendance.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 interface CurrentScolarYearProvider { public function getCurrentScolarYear() : ScholarYear; } final class DateHelper implement CurrentScolarYearProvider { public function getCurrentScolarYear() : ScholarYear { // Ton code } } final class MyController { private $helper; public function __construct(CurrentScolarYearProvider $helper) { $this->helper = $helper; } public function myAction() { return [ 'current_scolar_year' => $this->helper->getCurrentScolarYear(), ]; } }
Là, ton code est testable, et tu peux changer à la demande l'implémentation de ton provider.

16/03/2018, 10h13
grunk

Citation:

Envoyé par tdutrion

Je suis étonné de voir autant de personnes proposer une statique...

Que ce soit les traits ou la statique, au moment de tester unitairement vos classes vous allez galérer...

Dans la réalité les gens qui on le temps et/ou le budget d'unit tester tout le code c'est une minorité. (perso je l'ai pas)
Du coup les statiques ont du sens car il y'a beaucoup moins d'overhead qu'avec une injection de dépendance tout en gardant une organisation relativement propre.

Peux tu détailler en quoi ca va être un problème au moment d'un test unitaire ? Si la classe statique est testée , on à pas besoin de la retester dans la classe qui l'utilise non ?
16/03/2018, 10h52
tdutrion

En fait tu as d'une part le problème de la statique dans le test, car ta statique va te donner disons "2017-2018" pour l'exemple, mais lorsque tu passes à l'année "2018-2019" ton test ne passera plus (car la valeur change, donc le résultat change).

Si tu fais un test ou tu assert = date('Y') . '-' . (date('Y')+1), tu mets du code dans ton test, donc pas essence c'est faussé.
Ce que tu veux savoir dans le test c'est "si j'entre avec 2017-2018, est ce que mon résultat contient bien cette valeur (transformée correctement). Du coup dans le cas du helper injecté tu peux facilement mocker la valeur.

Pour le coup, selon ton framework l'injection ne rajoute pas massivement d'overhead, ni en charge de processing, ni en developpement, car tu auras l'autowiring qui s'occupe de ça (dans mon exemple il faut juste binder ton implementation à ton interface en fait)
16/03/2018, 11h00
CinePhil
Merci pour vos avis.

Citation:

Envoyé par CosmoKnacki

Si plusieurs classes partagent une ou plusieurs méthodes, tu peux utiliser les traits.

J'avais survolé la description des traits et n'avait pas perçu leur utilité.
C'est souvent quand on est confronté à un problème qu'on comprend l'utilité de l'outil mystérieux qui traîne dans un coin. :)

Citation:

Envoyé par grunk

Pour moi la bonne pratique c'est la création de ce qu'on va appeler des "helpers".

Quel serait l'avantage par rapport au trait ?
La classe helper ne pourrait-elle pas être un trait ? N'est-ce finalement pas équivalent ?

Citation:

Envoyé par tdutrion

Pour moi la vraie "bonne pratique" dans ce cas est l'injection de dépendance.

Qu'appelles-tu injection de dépendance ?
Citation:
Code:

1 2 3 4 interface CurrentScolarYearProvider { public function getCurrentScolarYear() : ScholarYear; }
Je n'ai pas encore rencontré cette syntaxe avec le :.
Ça veut dire quoi ?
En plus, tu ne réutilise pas ScholarYear plus loin dans le code.

En matière de test, j'essaie de tester mon code au fur et à mesure et de :
- déboguer de suite ;
- ou bien mettre des // FIXME ou // TODO pour déboguer ou améliorer plus tard.

Je vais essayer les traits.
16/03/2018, 11h04
tdutrion

L'inconvénient des traits c'est que c'est un vague copier coller conceptuellement, donc pas forcément propre.

Pour la parenthèse sur le : Valeur, c'est du PHP 7, c'est une façon de garantir le type de résultat (return types). En gros, si la méthode renvoi autre chose qu'un objet de type ScholarYear, on a une erreur.

Dans le cas de l'injection par rapport aux autres techniques, c'est que le jour où tu as besoin de changer l'implémentation de façon différente pour les différentes classes l'utilisant, tu n'auras que de la configuration à changer dans ton container (dans les factories).
16/03/2018, 11h13
CinePhil

Citation:

Envoyé par tdutrion

dans ton container (dans les factories).

"container", "factories"... voilà des trucs encore trop abstraits pour moi qui m'ont fait abandonné l'étude et l'envie d'utiliser les framework.

Mais c'est un autre sujet...

Ça semble cool, les traits ! :)

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
namespace Application\Controller;
 
trait DateHelper 
{
	/**
	 * Donne l'année universitaire en cours selon la date actuelle (Année 2017-2018 => 2017)
	 * @return int
	 */
	public function anneeUniv()
	{
		$today = getdate();
 
		if($today['mon'] > 7)
		{
			$anneeUniv = $today['year'];
		}
		else
		{
			$anneeUniv = $today['year'] - 1;
		}
 
		return $anneeUniv;
	}
 
}

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
class Ajouter extends Controleur
{
	use DateHelper
	{
			DateHelper::anneeUniv as anneeUniv;
	}
 
	public function index()
	{
		session_start();
 
		/** Vérification que l'utilisateur est connecté et à le droit d'accéder à la page */
		$this->verifierUtilisateur(); // vient du contrôleur générique Controleur
 
		/** Données pour la page */
		$anneeUniv = $this->anneeUniv(); // vient du trait DateHelper
// ...

La fonction s'utilise comme si c'était une fonction de la classe ou de la classe mère. 8-)

16/03/2018, 16h20
grunk
Citation:

Envoyé par CinePhil

Merci pour vos avis.

J'avais survolé la description des traits et n'avait pas perçu leur utilité.
C'est souvent quand on est confronté à un problème qu'on comprend l'utilité de l'outil mystérieux qui traîne dans un coin. :)

Un trait à l'avantage d'avoir accès à tous le scope d'une classe qui l'utilise. Ce n'est pas le cas d'une méthode/class statique.
une classe statique peut induire un couplage fort comme l'explique tdutrion. Celà peut être ennuyeux pour les tests unitaire , mais tu n'en ai pas là.

Citation:

Envoyé par CinePhil

La classe helper ne pourrait-elle pas être un trait ? N'est-ce finalement pas équivalent ?

Elle pourrait. C'est juste que conceptuellement c'est pas vraiment la même chose. Un traits - pour moi - c'est justement là pour éviter l'héritage fonctionnel. Ca te permet d'étendre les fonctionnalité d'une classe sans devoir dériver de quelque choses qui n'a aucun rapport.

Citation:

Envoyé par CinePhil

Qu'appelles-tu injection de dépendance ?

Une injection de dépendance c'est quand tu passe en paramètre une dépendance plutôt que de la coupler fortement :
Sans injection :
Code:

1 2 3 4 5 6 7 8 class A { public function __construct() { $b = new B(); $b->hello(); } }
On voit ici que si la classe B n'existe pas , la classe A ne fonctionne plus
Au contraire avec une injection de dépendance :
Code:

1 2 3 4 5 6 7 8 class A { public function __construct($b) { if($b) $b->hello(); } }
Je n'ai plus de couplage fort entre A et B , si B n'existe pas , A fonctionne toujours. Et je peux tout à fait passer ce que je veux en paramètre tant que ca répond au besoin de A.

Citation:

Envoyé par CinePhil

En matière de test, j'essaie de tester mon code au fur et à mesure et de :
- déboguer de suite ;
- ou bien mettre des // FIXME ou // TODO pour déboguer ou améliorer plus tard.

Les test unitaires dont parle tdutrion sont une autre facette de la programmation.
Tu écris des tests (des assertions) via un framework de test comme atoum,phpunit,etc ... et donc code finale doit permettre de passer ses tests.
Donc quand tu commences , aucun des tests ne passent car le code n'est pas ou mal écrit. Et au fur et à mesure on rempli les conditions des tests.
Ça à le très gros avantage de détecter les bugs rapidement et d'améliorer la qualité du code.

Citation:

Envoyé par CinePhil

"container", "factories"... voilà des trucs encore trop abstraits pour moi qui m'ont fait abandonné l'étude et l'envie d'utiliser les framework.

Mais c'est un autre sujet...

Ce sont des "design pattern" ou patron de conception en bon français ;)

ARF !

Citation:

Trait method anneeUniv has not been applied, because there are collisions with other trait methods

:aie:

Je n'ai qu'un seul trait et une seule méthode anneeUniv utilisée une seule fois dans la classe !
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 class Lister extends Controleur { use DateHelper { DateHelper::anneeUniv as anneeUniv; } // (...) protected function afficherListe($arguments) { $annee_univ_actuelle = $this->anneeUniv(); // (...) } }
Comment peut-il y avoir conflit ? 8O

EDIT : Le conflit provenait-il du fait que mon alias avait le même nom que la méthode du trait ?
En changeant l'alias, ça fonctionne.

17/03/2018, 09h50
Dendrite

Merci d'avoir posé tout haut une question que je me pose régulièrement, Cinéphil...
Personnellement, j'aime bien la solution des helpers...
Bon, ce sont des classes, mais au moins... ce n'est pas une classe fourre-tout qui s'appelle Tools et qui me rappellent fâcheusement mon ancien fonctions.php... :)
Je vais partir sur Date_helper et Regex_helper... Thx !

Bonjour,

Citation:

Envoyé par CinePhil

Le conflit provenait-il du fait que mon alias avait le même nom que la méthode du trait ?

Oui.
Cela n'a pas de sens de donner un alias du même nom.
De plus, il ne s'agit pas de renommer, les deux noms sont utilisables (d'où le conflit s'ils sont les mêmes) :
Code:

1 2 3 4 5 6 7 8 9 10 use DateHelper { anneeUniv as autreNom; } protected function afficherListe($arguments) { $annee_univ_actuelle = $this->anneeUniv(); //ou $annee_univ_actuelle = $this->autreNom();
Concernant la méthode "anneeUniv", je réduirais bien le code ainsi :
Code:

1 2 $today = getdate(); return $today['year'] - (int)($today['mon'] < 8); //(int) facultatif
Cela reste lisible.

17/03/2018, 11h27
tdutrion

Je trouve ça marrant quand même de demander la "Bonne pratique POO" et de se réjouir de la pire pratique en terme de POO (les traits sont de loin la moins bonne pratique de toutes celles exposées).

Si vous voulez vraiment suivre les bonnes pratiques POO, c'est injection de dépendance et c'est tout. Sinon c'est un choix de développement pour la simplicité sur le moment, je dis pas qu'il faut pas utiliser ces techniques, mais juste être conscient que ce n'est pas de la POO propre.
19/03/2018, 12h13
CinePhil

Citation:

Envoyé par tdutrion

L'inconvénient des traits c'est que c'est un vague copier coller conceptuellement, donc pas forcément propre.

En quoi c'est un copier-coller ?
La fonction est écrite une seule fois dans le trait et utilisée dans plusieurs classes. Je ne vois pas de copier-coller.

Citation:

Envoyé par tdutrion

Si vous voulez vraiment suivre les bonnes pratiques POO, c'est injection de dépendance et c'est tout.

Bis repetita :

Citation:

Envoyé par CinéPhil

Qu'appelles-tu injection de dépendance ?

:?

Pour ta remarque :

Citation:

Envoyé par tdutrion

Je trouve ça marrant quand même de demander la "Bonne pratique POO" et de se réjouir de la pire pratique en terme de POO (les traits sont de loin la moins bonne pratique de toutes celles exposées).

Comme je ne vois pas pourquoi... :?

Et comme ce que tu as évoqué plus haut "dans ton container (dans les factories)." reste trop abstrait et obscur pour mon faible niveau en POO... :?

Je prends donc ce que j'ai compris et qui semble me convenir pour le moment.

Moi je trouve un peu désolant de se plaindre qu'on ne choisit pas la bonne technique mais ne pas faire preuve de la pédagogie nécessaire pour expliquer pourquoi et quelle serait concrètement la bonne pratique. :mrgreen:

Grunk a fait l'effort, sans râler.
19/03/2018, 12h20
CinePhil
Citation:
Envoyé par grunk

Une injection de dépendance c'est quand tu passe en paramètre une dépendance plutôt que de la coupler fortement :
Sans injection :

Code:

1 2 3 4 5 6 7 8 class A { public function __construct() { $b = new B(); $b->hello(); } }

On voit ici que si la classe B n'existe pas , la classe A ne fonctionne plus
Au contraire avec une injection de dépendance :

Code:

1 2 3 4 5 6 7 8 class A { public function __construct($b) { if($b) $b->hello(); } }

Je n'ai plus de couplage fort entre A et B , si B n'existe pas , A fonctionne toujours. Et je peux tout à fait passer ce que je veux en paramètre tant que ca répond au besoin de A.
Ah OK ! Ben ça je pratique aussi mais je n'en vois pas trop l'intérêt dans le cadre qui me préoccupe ici.
Ça pourrait avoir du sens si c'est une classe métier qui possède une propriété valuée par une fonction externe mais là il s'agit d'un contrôleur du module. Ça me semble sémantiquement moins pertinent.
19/03/2018, 12h50
tdutrion

Justement je vois que tu as lu la réponse de Grunk, je n'ai pas répondu sur ce point car sa définition est bonne.

Le container, c'est ce qui va permettre de connaitre les "recettes" (factory) permettant de construire les différents objets (pour ne pas répéter l'instanciation des objets injectés et de l'objet principal partout).

Concrètement l'intérêt ici n'existe qu'avec l'utilisation d'une interface, et c'est précisément la substitution de Liskov dans les principes SOLID. Imaginons que tu ais 4 contrôleurs utilisant ton helper, et d'un coup l'un d'entre eux doit reposer sur une implémentation légèrement différente (chercher la donnée ailleurs par exemple), comment fais-tu ?
Avec un container et de l'injection de dépendance, 3 contrôleurs ne changent pas, et pour le 4ème tu dois juste changer une configuration de ton container pour injecter la nouvelle implementation.

Pour en revenir au traits, ce n'est pas un pure copier coller dans le sens ou changer l'implementation la changera partout, mais c'est un copier coller conceptuel (je colle ce code dans toutes les classes utilisant le trait). C'est donc un peu moins pire, mais ça introduit un couplage fort (changer l'implementation peut casser le reste).

Pour ce qui est de ma pédagogie, désolé mais je ne peux pas écrire un bouquin sur l'OOP là, il faut demander des ressources sur les points qui bloquent et pas dire ""container", "factories"... voilà des trucs encore trop abstraits pour moi qui m'ont fait abandonné l'étude et l'envie d'utiliser les framework.". Si les frameworks implémentent ces design patterns, c'est qu'ils ont une utilité. Pour le reste, il existe de très bonnes ressources qui expliquent ces concepts mieux que ce que je ferais ici avec mon temps limité, en info il faut aussi savoir chercher par soi-même.
20/03/2018, 22h07
alassanediakite

Salut
Voici une mine d'or que je vais copier/coller de suite sur le pense bête.
Mais une petite remarque pour tdutrion que je trouve un assez perfectionniste :ccool:...

Citation:

Envoyé par tdutrion

Concrètement l'intérêt ici n'existe qu'avec l'utilisation d'une interface, et c'est précisément la substitution de Liskov dans les principes SOLID. Imaginons que tu ais 4 contrôleurs utilisant ton helper, et d'un coup l'un d'entre eux doit reposer sur une implémentation légèrement différente (chercher la donnée ailleurs par exemple), comment fais-tu ?

Il y a le YAGNI qui nous permet de rester sur les classes STATIC (ma préférence) ou le trait (que je découvre :merci:). La volonté de factoriser ou de prévoir nous amène souvent à plus de complexité que de réels besoins.
Par ailleurs, pour le problème que vous citez
1->avec une classe STATIC on ajoute la nouvelle implémentation de la fonction et rien n’empêche d'enrichir l'ancienne (c'est en fait un module de fonctions utilitaires)
2->les TRAITS (tel que je viens de l'apprendre) pareil.
@+

Voir 40 message(s) de cette discussion en une page