Merci Julien pour cet article très intéressant. Nous l'avons utilisé comme support pour apprendre SOLID lors de l'un de nos dojos à Grenoble (CARA coding dojo). Nous avons utilisé aussi les principes avancés de Régis Médina.
Quelques points de ton article ont toutefois suscité des débats !
Par exemple la présentation de "Interface Segregation" dans l'article "Faites en sorte que vos objets ne se parlent pas directement, mais que chacun parle à une interface de l'autre" ne correspond pas bien à celle de Régis Médina "Les clients ne doivent pas être forcés de dépendre d'interfaces qu'ils n'utilisent pas."
L'exemple de l'article correspondrait plus à de l'inversion de dépendances (DIP), plutôt qu'à de la ségrégation d'interface.
Ensuite le D de SOLID correspond d'habitude plutôt à inversion de dépendances (DIP), plutôt qu'à l'injection de dépendances, non ? L'injection de dépendances est un outil (parmi d'autres) qui permet de respecter le principe de l'inversion de dépendances.
Plus au niveau du code, ton entité SessionStockage a nous a posé problème, car elle nous a paru avoir au moins deux responsabilités, à savoir le stockage, et le calcul du montant total du panier. Est-ce qu'il y avait une bonne raison de faire comme cela ? Cela nous semble violer le principe de responsabilité unique que justement tu invoques, et continue de maintenir une confusion entre les responsabilités de SessionStockage et Panier (et peut-être il y a une responsabilité non identifiée de Facturation).
Ce rôle un peu flou de SessionStockage apparaît aussi dans MockStockage, avec la duplication du code déjà présent dans SessionStockage, à savoir
$this->stock[$nom] += abs((float)$prix);
ainsi que
1
2
3
4
| public function total()
{
return array_sum($this->stock);
} |
Ces duplications de code semblent indiquer qu'il y a une responsabilité supplémentaire à factoriser. D'autre part elles affaiblissent beaucoup la valeur des tests, car ce qui est testé n'est pas exactement le code de production ! Enfin si on doit plus tard changer la logique métier de calcul du total (par exemple on a une réduction si on achète 2 fois le même article) il faudra toucher à la fois le code de production et le code de la doublure.
Enfin il nous est venu une question sur la classe Panier
1
2
3
4
5
6
7
8
9
10
11
| class Panier
{
protected $_stockage;
public function __construct(Stockage $s = null)
{
if ($s == null) {
$s = new SessionStockage("panier");
}
$this->setStockage($s);
} |
Pourquoi ce test sur null et la création dans ce cas de SessionStockage ? Cela maintient justement la dépendance que l'on voulait faire disparaître avec l'injection ?
Voilà les questions qui nous ont préoccupés !
Merci encore pour cet excellent sujet de discussion qui nous a bien occupés pendant 2H.
Bruno
PHPUnit avancé : patterns de tests
Répondre avec citation
Partager