Discussion :

[CinePhil]

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 ?

[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).

[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à

[grunk]

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 :

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

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 :

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

$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 ...)

[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...

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

Code :

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

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.

[grunk]

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 ?

[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)

[CinePhil]

Merci pour vos avis.

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.

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 ?

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

Qu'appelles-tu injection de dépendance ?

Code :

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

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.