Certains objets complexes nécessitent d'être construits ou paramétrés en plusieurs étapes, comme les composants d'une interface graphique (définition de leur taille, position, couleur...) ou les requêtes SQL (génération des clauses select, from, order by...),
Ces étapes sont matérialisées par un ensemble de méthodes, que le développeur doit appeler dans un ordre précis pour réaliser le processus de construction, au terme duquel l'objet finalisé lui est retourné. Ces méthodes peuvent appartenir à l'objet lui-même, ou à un objet externe implémentant le design pattern Builder.

Afin de simplifier la vie du développeur et de rendre le code plus lisible, il est intéressant de coder ces méthodes de manière à pouvoir chaîner leurs appels : l'objet possède alors une interface dite "fluide" (fluent en anglais).
Il suffit pour cela que chaque méthode renvoie l'instance courante de l'objet auquel elle appartient :

public class Foo {
	public Foo method() {
		(...)
		return this;
	}
}

Cet article expose la principale limitation de cette approche et propose une méthode simple pour la contourner, grâce à la technique des Self-Bounded Generics.

Exemple : BasicQueryBuilder

Tout au long de l'article, je prendrai comme exemple un générateur de requêtes SQL.

En voici une implémentation très basique, qui gère les clauses select, from, et where :

public class BasicQueryBuilder {
 
	protected StringBuilder buf = new StringBuilder();
 
	public String getQuery() {
		return buf.toString();
	}
 
	public BasicQueryBuilder select(String... fields) {
		buf.append("SELECT ");
		buf.append(join(", ", fields));
		return this;
	}
 
	public BasicQueryBuilder from(String... tables) {
		buf.append("\nFROM ");
		buf.append(join(", ", tables));
		return this;
	}
 
	public BasicQueryBuilder where(String... criteria) {
		buf.append("\nWHERE ");
		buf.append(join(" and ", criteria));
		return this;
	}
 
	protected String join(String separator, Object... objects) {
		StringBuilder builder = new StringBuilder();
		boolean first = true;
		for (Object o : objects) {
			if (first) {
				first = false;
			} else {
				builder.append(separator);
			}
			builder.append(o);
		}
		return builder.toString();
	}
 
}

Elle s'utilise comme suit :

// Trouver les liens vers TheCodersBreakfast.net
BasicQueryBuilder builder = new BasicQueryBuilder();
builder.select("visit.referrer")
	.from("visit","blog")
	.where("visit.blogId=blog.id", "blog.name='TheCodersBreakfast.net'");
System.out.println(builder.getQuery());

Ce qui donne le résultat souhaité :

SELECT visit.referrer
FROM visit, blog
WHERE visit.blogId=blog.id and blog.name='TheCodersBreakfast.net'

Interfaces fluides et extensibilité : AdvancedQueryBuilder

Les utilisateurs du BasicQueryBuilder réclament maintenant des fonctionnalités supplémentaires, comme la gestion des clauses orderBy, groupBy et having.

Pour une quelconque raison, il nous est interdit de modifier le code source du BasicQueryBuilder ; nous allons donc le sous-classer :

public class AdvancedQueryBuilder extends BasicQueryBuilder {
 
	public AdvancedQueryBuilder orderBy(String... orders) {
		buf.append(" ORDER BY ");
		buf.append(join(", ", orders));
		return this;
	}
 
	public AdvancedQueryBuilder groupBy(String... groups) {
		buf.append(" GROUP BY ");
		buf.append(join(", ", groups));
		return this;
	}
 
	public AdvancedQueryBuilder having(String... criteria) {
		buf.append(" HAVING ");
		buf.append(join(" and ", criteria));
		return this;
	}
 
}

Notez que le type de retour des méthodes est désormais AdvancedQueryBuilder et non plus BasicQueryBuilder.

Nous devrions maintenant pouvoir construire des requêtes plus complexes :

// Sélectionner les blog français influents
AdvancedQueryBuilder builder = new AdvancedQueryBuilder();
builder.select("blog.name","count(visit.id)")
	.from("visit", "blog")
	.where("blog.language='fr'")
	.groupBy("blog.name")
	.having("count(visit.id) > 1000");
System.out.println(builder.getQuery());

Mais cela ne compile pas !
Le problème se situe à la ligne 6. En effet, la méthode where() appartient à la classe BasicQueryBuilder et renvoie donc une instance de ce type... sur laquelle on ne peut pas appeler la méthode groupBy(), qui n'est définie que dans AdvancedQueryBuilder !

Une solution qui pourrait venir à l'esprit serait de modifier les signatures des méthodes de la classe BasicQueryBuilder afin qu'elle renvoie des instances de AdvancedQueryBuilder.
D'un point de vue architecture, ce serait évidemment une catastrophe ; en particulier, les méthodes de la classe mère ne pourraient plus être appelées que via sa classe fille...

Les Self-Bounded Generics à la rescousse

Il nous faut donc trouver un système permettant à la classe mère de renvoyer dynamiquement le bon type d'instance, en fonction de son contexte d'appel (depuis la classe elle-même ou depuis l'une de ses sous-classes).

Depuis Java 5, il est possible de paramétrer dynamiquement une instance de classe grâce aux types paramétrés (generics en anglais). Vous utilisez ce système tous les jours avec l'API Collections :

List<Blog> blogs = new ArrayList<Blog>()
blogs.add(new Blog());

Amélioration du BasicQuerybuilder

Dans l'exemple ci-dessus, le fait de paramétrer la classe ArrayList avec le type Blog a modifié la signature de ses méthodes. Ainsi, la méthode add() a accepté une instance de Blog en paramètre, au lieu d'un simple Object. Nous allons utiliser le même système pour définir le type de retour des méthodes de notre générateur de requêtes :

public class BasicQueryBuilder<T> {
 
	public T select(String... fields) {
		buf.append("SELECT ");
		buf.append(join(", ", fields));
		return (T) this;
	}
 
	(idem avec les autres méthodes)
}

Désormais, le type de retour des méthodes sera celui du type paramétré de la classe.
Mais attention, le cast de la ligne 6 impose que ce type soit compatible avec BasicQueryBuilder, c'est-à-dire BasicQueryBuilder lui-même ou l'une de ses sous-classes. Nous devons donc modifier la définition de la classe comme ceci :

public class BasicQueryBuilder<T extends BasicQueryBuilder<?>> 
{ ... }

Nous voyons ici pourquoi cette technique est appelée "Self-Bounded Generics" : le type de la classe apparaît dans l'expression de son paramètre.

Amélioration de l'AdvancedQuerybuilder

Voyons maintenant les modifications à apporter à l'AdvancedQueryBuilder.

Tout d'abord, il faut modifier sa définition de manière à paramétrer sa classe mère :

public class AdvancedQueryBuilder extends BasicQueryBuilder<AdvancedQueryBuilder> 
{ ... }

Grâce à cela, les méthodes héritées de BasicQueryBuilder renvoient bien des instances de type AdvancedQueryBuilder, et le code qui posait problème tout à l'heure fonctionne désormais :

// Sélectionner les blog français influents
AdvancedQueryBuilder<?> builder = new AdvancedQueryBuilder<AdvancedQueryBuilder<?>>();
builder.select("blog.name","count(visit.id)")
	.from("visit", "blog")
	.where("blog.language='fr'")
	.groupBy("blog.name")
	.having("count(visit.id) > 1000");
System.out.println(builder.getQuery());

Et l'on obtient :

SELECT blog.name, count(visit.id)
FROM visit, blog
WHERE blog.language='fr'
GROUP BY blog.name
HAVING count(visit.id) > 1000

But wait, there's more !

Nous avons maintenant un BasicQueryBuilder et un AdvancedQueryBuilder joliment architecturés et extensibles.
Extensibles, vraiment ? Et si les utilisateurs réclament un SuperAdvancedQueryBuilder avec encore davantage de fonctionnalités ?

Afin d'être totalement extensibles, il est nécessaire de répéter le processus de générification à tous les niveaux de la hiérarchie.
La définition de l'AdvancedQueryBuilder devient logiquement :

public class AdvancedQueryBuilder<T extends AdvancedQueryBuilder<?>> extends BasicQueryBuilder<T>
{ ... }

Et il s'instancie comme ceci :

AdvancedQueryBuilder<?> builder = new AdvancedQueryBuilder<AdvancedQueryBuilder<?>>();
(...)

SuperAdvancedQueryBuilder

Et pour satisfaire nos utilisateurs, développons donc un SuperAdvancedQueryBuilder sur le même modèle :

public class SuperAdvancedQueryBuilder<T extends SuperAdvancedQueryBuilder<?>> extends AdvancedQueryBuilder<T> {
 
	public T comment(String comment) {
		buf.append("\n-- ").append(comment);
		return (T) this;
	}
 
}

Qui s'utilise comme ceci :

SuperAdvancedQueryBuilder<?> builder = new SuperAdvancedQueryBuilder<SuperAdvancedQueryBuilder<?>>();
builder
	.select("blog.name", "count(visit.id)")
	.from("visit", "blog")
	.where("blog.language='fr'")
	.groupBy("blog.name")
	.having("count(visit.id) > 1000")
	.comment("This is a comment");
System.out.println(builder.getQuery());

Et donne ce résultat :

SELECT blog.name, count(visit.id)
FROM visit, blog
WHERE blog.language='fr'
GROUP BY blog.name
HAVING count(visit.id) > 1000
-- This is a comment

Conclusion

La technique des Self-Bounded Generics demande une certaine maîtrise des types paramétrés, mais permet de développer des interfaces fluides automatiquement extensibles.
La prochaine fois que vous implémentez de telles interfaces, pensez à ce pattern !

Le code source est disponible en annexe de ce billet.