Nous avons vu précédemment les requirements de notre POC pour mettre en pratique le concept de Fluent Interface sur une petite API de critères de recherche pour une requête SQL.
Structure d’un clause WHERE
Commençons par étudier la structure d’une clause WHERE en SQL.
criteria := criteria 'and' criteria criteria := criteria 'or' criteria criteria := fieldname operateur literal criteria := fieldname is null criteria := fieldname is not null operateur := '=' operateur := '>' operateur := '>=' ... avec fieldname : le nom d'un champ de la table et literal une valeur numérique ou une chaine de caractères
Si on regarde bien notre clause WHERE, on voit que l’on peut toujours la découper de plus en plus finement pour obtenir un critère minimal de recherche (un « egale », ou un « is null », …). Chacun de ces critères sont collés au suivant soit par des AND soit par des OR. Les priorités de ces deux mots clés n’étant pas toujours clairs quand on regarde une requête complexe, j’ai pris la décision d’encapsuler chaque partie de mes critères des AND et des OR dans des parenthèses. Cela alourdi légèrement la requête générée mais facilite grandement la compréhension.
La classe de base : Criteria
Donc on va commencer par la classe principale de notre API : la classe Criteria.
Chaque critère pourra être chainé à un autre soit en faisant un and() soit un or().
Chaque critère sera responsable de générer la portion de SQL correspondant à lui même.
-
package com.fluminis.criteria.internal.criteria;
-
-
public abstract class Criteria {
-
-
public Criteria and(Criteria o2) {
-
return new AndCriteria(this, o2);
-
}
-
-
public Criteria or(Criteria o2) {
-
return new OrCriteria(this, o2);
-
}
-
-
public abstract String generateSQL();
-
}
Gestion des AND et des OR
Un AND n’est autre qu’un Criteria qui fait l’union de deux autres Criteria avec un mot clé AND :
Comme mentionné plus haut, pour gérer facilement les priorités des opérateurs, on ajoute des parenthèses autours des deux critères.
-
package com.fluminis.criteria.internal.criteria;
-
-
public class AndCriteria extends Criteria {
-
-
private final static String AND = " AND ";
-
-
private final Criteria o1;
-
private final Criteria o2;
-
-
public AndCriteria(Criteria o1, Criteria o2) {
-
this.o1 = new Parenthesis(o1);
-
this.o2 = new Parenthesis(o2);
-
}
-
-
@Override
-
public String generateSQL() {
-
StringBuilder sb = new StringBuilder(o1.generateSQL());
-
sb.append(AND).append(o2.generateSQL());
-
return sb.toString();
-
}
-
}
(la classe OrCriteria est identique)
Et les parenthèses alors ?
La gestion des parenthèses est également facile. On peut se réprésenter cela comme un Criteria qui encapsule un autre Criteria.
-
package com.fluminis.criteria.internal.criteria;
-
-
public class Parenthesis extends Criteria {
-
-
private final static String OPEN_PARENTHESIS = "(";
-
private final static String CLOSE_PARENTHESIS = ")";
-
-
private final Criteria o;
-
-
public Parenthesis(Criteria o) {
-
this.o = o;
-
}
-
-
@Override
-
public String generateSQL() {
-
StringBuilder sb = new StringBuilder(OPEN_PARENTHESIS);
-
sb.append(o.generateSQL()).append(CLOSE_PARENTHESIS);
-
return sb.toString();
-
}
-
}
Les opérations booléennes
Bien maintenant, essayons de traiter les cas des opérations booléennes equals, greater, lesser, …
Si on décompose, il y a trois choses : le nom du champ, le signe de l’opération et la valeur.
On crée donc une classe abstraite pour mutualiser le comportement identique.
-
package com.fluminis.criteria.internal.criteria;
-
-
public abstract class Operand extends Criteria {
-
-
private final IField field;
-
private final Object value;
-
private final String operand;
-
-
public Operand(IField field, String operand, Object value) {
-
this.field = field;
-
this.operand = operand;
-
this.value = value;
-
}
-
-
@Override
-
public String generateSQL() {
-
StringBuilder sb = new StringBuilder(field.getName());
-
sb.append(operand).append(value);
-
return sb.toString();
-
}
-
}
-
-
public class Equals extends Operand {
-
public Equals(IField field, Object value) {
-
super(field, "=", value);
-
}
-
}
-
-
public class Greater extends Operand {
-
public Greater(IField field, Object value) {
-
super(field, ">", value);
-
}
-
}
-
…
Le « is null » et « is not null » ne sont pas des Operand, mais de simples Criteria
-
package com.fluminis.criteria.internal.criteria;
-
-
public class IsNull extends Criteria {
-
-
private final IField field;
-
-
public IsNull(IField field) {
-
this.field = field;
-
}
-
-
@Override
-
public String generateSQL() {
-
StringBuilder sb = new StringBuilder(field.getName());
-
sb.append(" IS NULL");
-
return sb.toString();
-
}
-
}
Comme vous l’aurez surement remarqué, nous n’utilisons pas des String pour le nom des champs mais des IField. Cela nous assure que le développeur ne sera pas tenté de manipuler des String à tout bout de champ.
-
package com.fluminis.criteria.internal.criteria;
-
-
public interface IField {
-
String getName();
-
}
Ok pour aujourd’hui. Nous verrons dans la prochaine partie comment gérer les types de données et comment réunir tout cela pour faire fonctionner notre API.
How To : Concevoir une API Fluent – Partie 3