Alors t ou maintenant ? (coachC si tu te rappel …)

sur le diagramme UML il n’y a pas les informations de visibilités.

Le constructeur AbstractCompositeSpecification est en visibilité « protected ».

Pour plus d’informations voici mon implémentation de cette classe : http://nicolaslecoz-dev-sandbox.googlecode.com/svn/trunk/nlc-java-sandbox/src/main/java/patternSpecification/regleMetier/util/AbstractCompositeSpecification.java

Bon courage.

Je démarre la mise en place de pattern pour l’implémentation de règles de gestion. Ce tuto m’a bien éclairé. J’ai néanmoins une question sur le contenu de la classe composite. Pourquoi contient elle un constructeur alors qu’elle est abstraite ?

Pouvez vous publier son contenu ? (car j’ai un doute sur mon implémentation, actuellement ma classe composite implémente les méthodes and(), or().. de la manière suivante :

public Specification and(Specification specification) {
return new AndSpecification(this, specification);
}

Mais je n’ai pas de constructeur

Merci !!

Je n’ose pas dire que Martin Fowler à tord et que j’ai raison . Voici mon explication :

Il n’y a pas d’erreur dans mon diagramme de classe. J’ai sciemment fait hériter ma classe « LeafSpecification » de la classe parente « …CompositeSpecification ».

Pour la simple est bonne raison que je voulais faire un DSL de toutes mes règles métiers (NB : ce n’est pas une obligation).

Ainsi avec n’importe quelle règle métier je peux faire :

regle1.and(regle2.or(regle3. … ))).and(…).or(…);

J’aurais pû me contenter d’utiliser les opérateurs java mais on perd rapidement en lisibilité du code (surtout quand on veut gérer des règles prioritaires par rapport aux autres grâce au parenthèsage).

En d’autres mots, je me suis permis d’apporter un petit gravion dans l’immense édifice qu’à réaliser maître Martin Fowler B-).

Nicolas LC (Xebia)

Dîtes moi si je me trompe mais n’y a-t-il pas une erreur dans votre diagramme de classe ? J’ai lu le PDF de Mr Fowler et il se trouve qu’une LeafSpecification n’est pas censée être une CompositeSpecification (cf. p12) Idem pour la NotSpecification.

Cordialement,

Mickaël.

J’aurai une petite question à vous posez.
Ce pattern – comme de nombreux autres – s’applique sur la couche métier de nos architectures.
Comment peut-on l’utiliser au niveau de la couche de persistance ?

Au sein de mon entreprise, nous avons des règles métier qui vont surement évoluées dans le temps.
Ces règles nous permettent de savoir quelles données nous devons remonter de la base de données vers la présentation utilisateur.
Par exemple, nous avons une contrainte sur l’appartenance à un pays. Nous effectuons donc une requête SQL en ajoutant une condition sur une jointure.
Sachant que nous utilisons cette condition sur l’ensemble des requêtes, si les règles métiers changent, nous devrons repasser sur l’ensemble de ces requêtes pour ajouter/enlever des conditions.
On retrouve le pourquoi du comment du pattern Specification au niveau métier.

Il est possible d’implémenter ce pattern pour l’accès aux données persistantes. Le soucis, c’est que chaque règle supplémentaire a un cout important car il s’agit d’un aller/retour vers la base de données. 3 milles produits x 4 règles, on explose le compteur rapidement avec 200 demandes simultanées.

Avez-vous une solution implémentation du pattern Specification pour l’accès aux données ?

Cordialement,
Thomas Tourlourat – Armetiz.info

Plus d’informations : http://chtijug.org/rendez-vous-le-21-janvier-drools-avec-cylande-et-luniversite-de-lille-1/

@Dun, pour gérer un contexte il y a deux possibilités. 1 – soit tu gardes le modèle de l’article avec les règles qui prennent en argument des objets du modèle. Tu géres le « ALORS » en dehors des règles.
2 – Sinon tu peux te rapprocher d’un modèle à la Drools. Tu as des règles fines qui utilisent les objets du domaine. Tu as un (ou des) règle de plus haut niveau qui eux utilisent un objet contexte. Dans cet objet contexte on peut injecter un service à appeler dans le « ALORS »,
@Herve A. ce contexte peut aussi servir avoir une trace de l’information ou un état d’exécution.

Par exemple je prends un cas concret. Prenons un algorithme métier pour l’éligibilité des moyens de livraison en fonction du panier. Il faut donc créer un objet contexte à cet algorithme qui va contenir les données d’entrée (le panier, ou autre) et les données de sortis, les moyens de livraison et le prix associé. On a donc maintenant des règles qui sont capables de calculer un resultat plus évolué que « oui » / « non ».

Merci pour le travail de rédaction.

Le pattern semble gérer le « SI » mais pas le « ALORS » contrairement à ce que ferait un Drools. Comment gérer de façon propre et isolé ces « constantes » de poids qui finalement risque de changer plus rapidement que les règles définissant si le client et de France métropolitaine ou pas ?

Merci tu as détecté un bug . J’ai corrigé mais je suis par forcement satisfait du résultat :

public class RegleProduitsDuPanierSontOranges extends LeafSpecification {
public boolean isSatisfiedBy(Panier panier) {
for (Produit produit : panier.getProduits()) {
if ( ! (produit instanceof Abricot
|| produit instanceof Carotte
|| produit instanceof Citrouille
|| produit instanceof Mandarine
|| produit instanceof Orange)) {
return false;
}
}
return true;
}
}
Je ne voulais pas en parler dans l’article mais on peut aussi utiliser une sorte de pattern visiteur, par exemple un parcours en « et » sur les produits d’un panier.

Par exemple la classe qui s’occupe du parcours :

public abstract class ParcoursEnEtSurProduitsDuPanier extends LeafSpecification {
abstract protected boolean isProduitSatisfiedBy(Produit produit);
public boolean isSatisfiedBy(Panier panier) {
for (Produit produit : panier.getProduits()) {
if ( ! isProduitSatisfiedBy(produit)) {
return false;
}
}
return true;
}
}
La classe qui implémente la règle sur un produit :


public class RegleProduitEstOrange extends ParcoursEnEtSurProduitsDuPanier {
protected boolean isProduitSatisfiedBy(Produit produit) {
if (produit instanceof Abricot
|| produit instanceof Carotte
|| produit instanceof Citrouille
|| produit instanceof Mandarine
|| produit instanceof Orange) {
return true;
}
return false;
}
}

Voila je pense que c’est un peu plus lisible.

Petite exclusivité, la semaine prochaine, il y aura un prochain article sur Drools . Selon moi ce pattern peut rapidement être mis en place avec un cout et temps minimum dans les équipes de développement, contrairement à Drools. Drools est un framework assez complexe mais pas insurmontable. Ce framework a de nombreux avantages, mais les fonctionnalités doivent bien être maitrisées afin de se lancer (DSL, table de décision via fichier Excel, IHM, langage MVEL (drools), … ).

Drools demande de former les développeurs et de faire idéalement un prototype. Cependant Drools est relativement facilement intégrable dans un projet existant. On peut envisager d’intégrer en douceur Drools c’est à dire algorithme par algorithme.

- gestion de règle à chaud -

@Ga.K

Concernant la gestion de règle à chaud c’est assez simple, en fait notre solution finale combine une solution Java avec ce pattern et du Groovy, pour sa syntaxe puissante. De plus on utilise le module Spring pour le support dynamique de langage : http://static.springsource.org/spring/docs/2.0.x/reference/dynamic-language.html.
Donc la modification de certaines règles se résume à un redéploiement des fichiers Groovy, après Spring fait le reste . Après il faut trouver un bon compris entre développement en Java et Groovy.

Je trouve ça pas mal, peut être faudrait-il y adjoindre un contexte d’opération ? Les règles sont souvent intitulées xxxDuPanierYyy, cela ne serait pas mieux que de formaliser ce DuPanier, histoire de ne pas appliquer des règles DuPanier à des objets DeLivraison, par exemple ?

Moi aussi j’ai beaucoup lorgné du coté de drools, toujours pour conclure avec grand regret que c’était trop compliqué pour moi. Si quelqu’un peut me démontrer que je me suis trompé, j’en serais fort content. J’en suis arrivé à penser qu’on pouvait peut être traiter les règles par un jeu de routes à la mode Camel, mais j’en suis aux supputations des considérations.

Cependant je voudrais aller plus loin et retourner la ou les raisons de l’échec de l’application d’une règle métier afin que l’utilisateur sache où corriger son erreur. J’ai fait en sorte que la spécification retourne une paire contenant le boolean classique et la raison de l’échec si false.
Là, j’ai un problème…
En effet les combinaisons de spécifications peuvent être complexes, et par conséquent la raison de l’échec est difficilement exprimable. Peut être est-ce normal; ou alors je m’y prends mal.

Quelqu’un aurait une idée?

Par contre, comment remonter -simplement- la bonne information en cas d’échec d’une des spécifications? Ceci est encore plus important si vous enchaînez plusieurs spécifications. C’est, à ce jour, la seule limite que nous avons trouvée à ce pattern…

Au final, le plus important est de ce concentrer sur votre modèle Objet (anémique ou riche?). Le pattern Specification convient à un certain type de « règles métier », mais peut-être pas pour toutes (attention au marteau…).

Merci pour vos articles et bonne année 2010!

Je suis curieux de savoir pourquoi Drools semblait trop complexe…

Sinon, à mi-chemin, comme mentionné dans un commentaire précédent, l’usage d’un DSL semble effectivement une option.

Autre solution, que j’ai vu appliquée : au lieu d’avoir des des gens qui veulent n’importe quoi et qui oublient d’un jour sur l’autre ce qu’ils voulaient – Et oui…. ça peut amener à ça aussi, de donner la main sur les règles métier à des gens pas totalement férus de logique… – avoir une cellule archi/développement stable qui est garante des règles métier.

Autre solution, le dsl. Sorte de sur-mesure de la gestion des règles métier. La création d’objets qui obéissent à un pattern aidera tout de même pas mal à la création d’un dsl. On le voit, dans le code présenté ici en exemple

Bonne année, les xebia boys!