Le Design pattern : Specification

Comme chaque patron de conception, la spécification vient résoudre une problématique, celle des règles métiers. Même si dans cet article nous allons prendre des exemples très simple pour aborder la notion, il faut garder en tête cet objectif de “moteur de règle” / gestion des règles métiers.

Pour se représenter cette notion, vous pouvez imaginer un appareil qui vient scanner un type d’information et vous informe si vous êtes autorisé à passer… ou pas. Par exemple, vous scannez votre carte d’identité et de fait, vous savez immédiatement quelles sont vos différentes autorisations. C’est donc très utile pour une gestion complexe de rôles au sein d’une application. Avec ce pattern, vous allez pouvoir centraliser et réutiliser toute la complexité des conditions nécessaires pour accéder à une action. Il devient beaucoup plus facile de comprendre la condition nécessaire à remplir pour n’importe quel développeur ; voyons plutôt.

Voici une condition très simple. Jusque là, rien d’extraordinaire, si le rôle de notre utilisateur est admin alors on exécutera l’ensemble du code de la condition. Or, ce genre de condition présente plusieurs risquent :

• Je n’utilise pas la triple égalité. C’est toujours “mieux”
• Quid si demain les rôles deviennent des integer et plus des strings ? Il faudra repasser sur l’ensemble de l’application…
• Ici, j’ai bien écrit admin. Or, combien ont-ils déjà fait des erreurs classiques en oubliant des points virgules ? Vous pourriez tout autant écrire admmin avec 2 “M” sans faire exprès et créer des problèmes applicatifs.
• La condition est lisible et compréhensible, mais ce n’est pas toujours le cas.

Prenons le même exemple en éliminant l’aspect lisible de la condition :

La variable est mal nommé, on ne comprend pas le “1” si l’on n’a pas connaissance de sa correspondance, toujours pas de triple égalité, etc…

Maintenant, allons plus loin dans nos conditions. Pour exécuter le code de la condition, on souhaite que l’utilisateur soit admin mais aussi qu’il ait l’autorisation de … boire du café ? et qu’il soit habillé en bleu ? qu’il fasse 170cm minimum OU 70kg minimum ? etc… Pourquoi pas ?

Ca devient compliqué on est d’accord ? Plutôt lisible mais clairement, personne n’a envie de lire ce genre de condition. Qui plus est, il devient difficile de faire l’association d’idée pour comprendre l’intérêt de ces conditions. C’est là que la Specification devient intéressante. Mais, soyez pragmatique. Ce n’est pas parce que vous avez une seule condition de ce type dans votre application qu’il faut impérativement implémenter le pattern Specification. Voyez plutôt à quoi ça ressemblerait avec une Specification

Plus simple ? Alors cela va donner le sentiment à certains d’avoir beaucoup d’objets, beaucoup de fichiers, etc… mais c’est plus lisible et beaucoup plus facile à maintenir.

Pour l ‘implémenter, je vous invite à lire ce bouquin : Design Patterns Elements Reusable. Si vous préférez internet, voici un lien qui vous parle de son implémentation : Design Pattern Php.