Discussion :

[Mister Tie]

Bonsoir à tous,

Je vous propose un article sur l'évolution de la construction d'objets en Java.
Où comment passer de l'antipattern Telescoping Constructor au Builder Pattern en prenant le temps de survoler les interfaces fluides (Fluent Interfaces).

Vos retours (positifs comme négatifs) sont importants; ils me permettent d'améliorer l'article et d'enrichir la réflexion qui l'entoure. N'hésitez donc surtout pas à poster.

L'article se trouve à l'URL suivante: http://cheliou.developpez.com/tutori...ject-building/.

Bien à vous,
Clément

[professeur shadoko]

je suggère de rajouter deux autres points de vue:
1) pour chaque champ le marquage de ce qui est forcément initialisé et ce qui peut être optionnel. C'est hyper important: une fois l'objet dans un état "stable" tous les champs obligatoires DOIVENT avoir été initialisé ... pour les autres un accesseur ("get") doit rendre un objet Optional.
2) distinguer les champs qui participent à la gestion et ceux qui sont "décoratifs". Les premiers sont des champs à part entière les seconds sont des propriétés que l'on peut fixer dynamiquement de différentes manières (je ne parle même pas des propriétés calculées comme l'age).
Quand le code évolue à l'usage certains champs décoratifs deviennent des champs de gestion. L'avantage de cette distinction est que l'on peut rapidement faire des classes pour réaliser des maquettes et d'autre part qu'on évite d'alourdir les classes d'une megach*** de spécifications pas vraiment utiles pour le fonctionnement métier du code.
L'exemple donné dans le document de tout ce qu'on peut attribuer à une personne est assez instructif: on a plein de "machins" qui sont des informations que l'on peut certes montrer mais qui n'ont aucune importance du point de vue de la gestion purement "métier".

[Mister Tie]

Bonsoir et merci pour vos suggestions auxquelles je vais tenter de répondre du mieux possible.

je suggère de rajouter deux autres points de vue:
1) pour chaque champ le marquage de ce qui est forcément initialisé et ce qui peut être optionnel. C'est hyper important: une fois l'objet dans un état "stable" tous les champs obligatoires DOIVENT avoir été initialisé ... pour les autres un accesseur ("get") doit rendre un objet Optional.

Le marquage doit/peut être fait au niveau de la classe à construire (via le mot clé final, via les Optionals pour indiquer l'absence possible, etc.). Dans tous les cas, cela ne me semble pas du ressort du bâtisseur.
L'instance créée par défaut est stable; il ne reste qu'à redéfinir les champs d'intérêts. Tout au plus peut-on obliger à renseigner tous les champs obligatoires; c'est ce que fait la librairie lombok-pg dans l'exemple que je donne. Néanmoins, je n'y vois pas un intérêt évident.

2) distinguer les champs qui participent à la gestion et ceux qui sont "décoratifs". Les premiers sont des champs à part entière les seconds sont des propriétés que l'on peut fixer dynamiquement de différentes manières (je ne parle même pas des propriétés calculées comme l'age).
Quand le code évolue à l'usage certains champs décoratifs deviennent des champs de gestion. L'avantage de cette distinction est que l'on peut rapidement faire des classes pour réaliser des maquettes et d'autre part qu'on évite d'alourdir les classes d'une megach*** de spécifications pas vraiment utiles pour le fonctionnement métier du code.
L'exemple donné dans le document de tout ce qu'on peut attribuer à une personne est assez instructif: on a plein de "machins" qui sont des informations que l'on peut certes montrer mais qui n'ont aucune importance du point de vue de la gestion purement "métier".

J'ai un peu de mal à faire la distinction entre les 2 types de champs; un exemple concret m'aiderait probablement à mieux comprendre.
En tout cas, cela me semble plus lié à la classe à instancier qu'au bâtisseur. Ce dernier joue son rôle en "cachant" les champs inutiles et en permettant de se concentrer sur ceux qui nous intéressent.

Bien à vous,
Clément

[professeur shadoko]

Tout au plus peut-on obliger à renseigner tous les champs obligatoires; c'est ce que fait la librairie lombok-pg dans l'exemple que je donne. Néanmoins, je n'y vois pas un intérêt évident.

C'est pourtant essentiel: dans un fonctionnement complexe si un objet se trouve à un moment sans un état "larvaire" on a des potentialités de bugs phénoménales. Dans mon projet (qui est très complexe du point de vue des Threads) j'ai demandé aux programmeurs (preuves de bugs à l'appui) d'éliminer tous les beans qui permettaient des initialisations incomplètes.

J'ai un peu de mal à faire la distinction entre les 2 types de champs; un exemple concret m'aiderait probablement à mieux comprendre.

l'exemple que je donne toujours est le suivant:
un "Livre" va avoir des tas de champs "de gestion" comme "titre", "isbn", "auteur", etc. Mais maintenant si tu veux pouvoir vendre un livre en disant que c'est un "IN-quarto, tiré sur Vélin d'Ingres, édition limitée à 50 exemplaires, signés par l'auteur" ... tu ne va pas créer des champs spécifiques pour ces informations. Elles sont bien présentes (et même analysables si on tire les choses par les cheveux) mais ce ne sont pas des champs (variables membres d'instance avec leur nom , leur type, etc..)

[Mister Tie]

C'est pourtant essentiel: dans un fonctionnement complexe si un objet se trouve à un moment sans un état "larvaire" on a des potentialités de bugs phénoménales. Dans mon projet (qui est très complexe du point de vue des Threads) j'ai demandé aux programmeurs (preuves de bugs à l'appui) d'éliminer tous les beans qui permettaient des initialisations incomplètes.

Sauf que, toute instance créée via le bâtisseur présenté aura ses champs obligatoires renseignés, possiblement avec des valeurs par défaut censées être cohérentes. L'initialisation est donc complète de ce point de vue. Le bâtisseur évite donc d'avoir ces états larvaires.

l'exemple que je donne toujours est le suivant:
un "Livre" va avoir des tas de champs "de gestion" comme "titre", "isbn", "auteur", etc. Mais maintenant si tu veux pouvoir vendre un livre en disant que c'est un "IN-quarto, tiré sur Vélin d'Ingres, édition limitée à 50 exemplaires, signés par l'auteur" ... tu ne va pas créer des champs spécifiques pour ces informations. Elles sont bien présentes (et même analysables si on tire les choses par les cheveux) mais ce ne sont pas des champs (variables membres d'instance avec leur nom , leur type, etc..)

Je comprends votre exemple. Comme dit précédemment, je pense que cela relève plus du design de la classe initiale (dans mon exemple, Person) que de celui du bâtisseur. On peut proposer plus ou moins de méthodes de surcharge; c'est à la discrétion du développeur et il est difficile d'en faire une règle générale.

J'espère avoir répondu le plus précisément possible à vos questions.

[Gabriel1234]

Bonjour,
il est possible de faire des builders abstraits de ce type :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
 
public abstract class AbstractBuilder<T extends AbstractBuilder<T>> {
 
	protected abstract T getThis();
 
	public T id(int id) {
		this.id = id;
		return getThis();
	}
 
	protected void setValuesBasic(MonObjet result) {
		result.setId(id);
	}
 
}
 
public class MonObjetBuilder extends AbstractBuilder<MonObjetBuilder> {
 
	protected MonObjetBuilder getThis() {
		return this;
	}
 
	public MonObjetBuilder field(float value) {
		this.field = value;
		return this;
	}
 
	public MonObjet build() {
		MonObjet result = new MonObjet();
		setValuesBasic(result);
		return result;
	}
 
}

[thelvin]

Et, euh... C'est intéressant d'avoir plusieurs builders différents mais répondant aux mêmes règles pour le même type d'objet ?

[regis1512]

Bonjour,

C'est un article très plaisant à lire et très intéressant.

Bonne journée.

[Mister Tie]

Bonjour,
il est possible de faire des builders abstraits de ce type :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
 
public abstract class AbstractBuilder<T extends AbstractBuilder<T>> {
 
	protected abstract T getThis();
 
	public T id(int id) {
		this.id = id;
		return getThis();
	}
 
	protected void setValuesBasic(MonObjet result) {
		result.setId(id);
	}
 
}
 
public class MonObjetBuilder extends AbstractBuilder<MonObjetBuilder> {
 
	protected MonObjetBuilder getThis() {
		return this;
	}
 
	public MonObjetBuilder field(float value) {
		this.field = value;
		return this;
	}
 
	public MonObjet build() {
		MonObjet result = new MonObjet();
		setValuesBasic(result);
		return result;
	}
 
}

Et, euh... C'est intéressant d'avoir plusieurs builders différents mais répondant aux mêmes règles pour le même type d'objet ?

Bonjour Gabriel et merci pour votre proposition.
Comme le souligne thelvin, j'ai un peu de mal à saisir l'intérêt d'un bâtisseur abstrait. Pouvez-vous nous donner un cas d'utilisation concret histoire que nous nous fassions une meilleure idée?

Bonjour,

C'est un article très plaisant à lire et très intéressant.

Bonne journée.

Merci beaucoup pour ce retour.

[Gabriel1234]

Et, euh... C'est intéressant d'avoir plusieurs builders différents mais répondant aux mêmes règles pour le même type d'objet ?

C'est rarement le cas sans doute, je l'utilise par exemple pour un requêteur Elastic Search/Solr.
Pour construire la requête, on sélectionne d'abord l'action puis on définit les différents attributs optionnels. Ainsi on peut faire un count, sélectionner les facettes, demander l'autocomplétion, ...
Je n'ai pas vraiment de règles, l'initialisation du builder demande les paramètres obligatoires.

Sinon très bon article, si seulement on pouvait avoir plus de builder!

[lolomadev]

Bonjour,

l'article est très plaisant à lire. Cependant au chapitre III-C-2, une classe est définie static
à plusieurs reprises :

public static class PersonBuilder { ...

C'est peut-être possible dans d'autres langages que Java.

Bonne journée,

Laurent

[thelvin]

Moi je voyais ça comme une question de contexte. De même que les méthodes et constructeurs de ce même article sont montrés seuls et pas encadrés de leur classe, il n'est dit nulle part que ces classes builder sont de premier niveau.
Assez souvent, le builder d'une classe est imbriqué à la classe elle-même, ce qui permet notamment de garder le constructeur et les champs de la classe, private.

... Ça n'a pas que du bon, par contre, parce que ça fait beaucoup de code dans la classe englobante. Et puis du coup, des constructions comme PersonBuilder.createDefaultPerson().build() nécessitent un import static de PersonBuilder. Moi je fais plutôt createDefaultPerson() comme méthode static de Person directement, dans ces cas-là.

[lolomadev]

Bonjour,

je continuais la lecture de cet article fort intéressant quand je me suis demandé pourquoi, au chapitre IV-A,
le modificateur d'accès protected est utilisé dans ParentBuilder.

protected est utilisé pour le constructeur et également pour les accesseurs getFieldA() et getFieldB().

Vu qu'il n'y a pas de relation d'héritage entre ChildBuilder et ParentBuilder, ni entre une autre classe et ParentBuilder,
on peut penser que les modificateurs d'accès de getFieldA() et getFieldB() devraient être les mêmes que
ceux de withFieldA() et withFieldB(), c'est-à-dire public (au cas où ChildBuilder ne serait pas dans le même
package que ParentBuilder).

Quand au constructeur je me suis dit qu'il pourrait très bien rester private, comme pour le PersonBuilder de la
section III-2-C, vu que l'instanciation de ParentBuilder est faite par la méthode public static createDefaultParent()
de la classe ParentBuilder.

Bonne journée,

Laurent

[Mister Tie]

Bonjour et merci pour vos retours.

Bonjour,

l'article est très plaisant à lire. Cependant au chapitre III-C-2, une classe est définie static
à plusieurs reprises :

C'est peut-être possible dans d'autres langages que Java.

Moi je voyais ça comme une question de contexte. De même que les méthodes et constructeurs de ce même article sont montrés seuls et pas encadrés de leur classe, il n'est dit nulle part que ces classes builder sont de premier niveau.
Assez souvent, le builder d'une classe est imbriqué à la classe elle-même, ce qui permet notamment de garder le constructeur et les champs de la classe, private.

... Ça n'a pas que du bon, par contre, parce que ça fait beaucoup de code dans la classe englobante. Et puis du coup, des constructions comme PersonBuilder.createDefaultPerson().build() nécessitent un import static de PersonBuilder. Moi je fais plutôt createDefaultPerson() comme méthode static de Person directement, dans ces cas-là.

L'exemple donné est un extrait du code source où le bâtisseur est englobé dans la classe construite.
La déclaration statique de la classe est donc, comme précisé par thelvin, liée au contexte.
Cela permet:

1. de garder un lien fort avec la classe construite;
2. de permettre l'usage du bâtisseur en dehors de la classe construite.

Vous pouvez voir l'exemple complet sur GitHub, comme précisé au début de l'article.

Bonjour,

je continuais la lecture de cet article fort intéressant quand je me suis demandé pourquoi, au chapitre IV-A,
le modificateur d'accès protected est utilisé dans ParentBuilder.

protected est utilisé pour le constructeur et également pour les accesseurs getFieldA() et getFieldB().

Vu qu'il n'y a pas de relation d'héritage entre ChildBuilder et ParentBuilder, ni entre une autre classe et ParentBuilder,
on peut penser que les modificateurs d'accès de getFieldA() et getFieldB() devraient être les mêmes que
ceux de withFieldA() et withFieldB(), c'est-à-dire public (au cas où ChildBuilder ne serait pas dans le même
package que ParentBuilder).

Il ne faut pas perdre de vue que la classe Child hérite de la classe Parent et que ces dernières contiennent respectivement les bâtisseurs ChildBuilder et ParentBuilder. C'est pourquoi les accesseurs ont la visibilité protected. Une visibilité plus grande (i.e. public) n'est pas utile car, à priori, la valeur à un instant T d'une variable d'instance d'un bâtisseur n'a pas d'intérêt à l'extérieur de celui-ci, sauf pour d'éventuelles bâtisseurs enfants.

Quand au constructeur je me suis dit qu'il pourrait très bien rester private, comme pour le PersonBuilder de la
section III-2-C, vu que l'instanciation de ParentBuilder est faite par la méthode public static createDefaultParent()
de la classe ParentBuilder.

Vous avez tout à fait raison.
C'est un résidu d'une précédente solution.
Je note cette remarque et ferai la correction d'ici à la fin de la semaine.

J'espère avoir répondu clairement à vos questionnements.
Bien à vous,

[Logan Mauzaize]

Excellent article

Je fais une petite intervention moins sur les builder que sur les fluent interface. Tu m'as convaincu
Cela n'a pour le moment pas eu de raison d'être dans le code applicatif mais dans celui des tests, cela permet de dégager une grande sémantique et une bonne organisation en crééant des APIs qui décrivent vraiment les cas de tests.

Je donne en exemple un test "tout-con" concernant l'implémentation d'un ListIterator inversé :

Code Java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
public class Scenario<E> {
  private List<E> liste;
  private ListIterator<E> iterateur = null;
 
  public Scenario(E... elements) {
    liste = new ArrayList<E>(Arrays.asList(elements));
  }
 
  public Scenario endroit() {
    iterateur = liste.listIterator();
    return this;
  }
 
  public Scenario envers() {
    iterateur = new InverseListIterator(liste); // Définit l'implémentation inversée
    return this;
  }
 
  public Scenario next(E element) {
    Assert.assertEquals(element, iterateur.next());
    return this;
  }
 
  public Scenario hasNoNext() {
    Assert.assertFalse(iterateur.hasNext());
    return this;
  }
 
  public Scenario nextIndex(int index) {
    Assert.assertEquals(index, iterateur.nextIndex());
    return this;
  }
 
  public Scenario previous(E element) {
    Assert.assertEquals(element, iterateur.previous());
    return this;
  }
 
  public Scenario hasNoPrevious() {
    Assert.assertFalse(iterateur.hasPrevious());
    return this;
  }
 
  public Scenario nextPrevious(int index) {
    Assert.assertEquals(index, iterateur.previousIndex());
    return this;
  }
 
  public Scenario add(E element) {
    iterateur.add(element);
    return this;
  }
 
  public Scenario remove() {
    iterateur.remove();
    return this;
  }
 
  public Scenario checkList(E... elements) {
    Assert.assertEquals(Arrays.asList(elements), liste);
    return this;
  }
}

Et un petit exemple d'utilisation :

Code Java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
class InverseListIterator {
  @Test
  public void testEndroit() {
    new Scenario<String>("a", "b")
      .endroit().next("a").next("b").hasNoNext()
      .endroit().add("c").next("a").next("b").hasNoNext()
      .checkList("c", "a", "b");
  }
  @Test
  public void testEnvers() {
    new Scenario<String>("a", "b")
      .envers().next("b").next("a").hasNoNext()
      .envers().add("c").next("b").next("a").hasNoNext()
      .checkList("a", "b", "c");
  }
}

[Mister Tie]

Excellent article

Je fais une petite intervention moins sur les builder que sur les fluent interface. Tu m'as convaincu
Cela n'a pour le moment pas eu de raison d'être dans le code applicatif mais dans celui des tests, cela permet de dégager une grande sémantique et une bonne organisation en crééant des APIs qui décrivent vraiment les cas de tests.

Je donne en exemple un test "tout-con" concernant l'implémentation d'un ListIterator inversé :

Code Java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
public class Scenario<E> {
  private List<E> liste;
  private ListIterator<E> iterateur = null;
 
  public Scenario(E... elements) {
    liste = new ArrayList<E>(Arrays.asList(elements));
  }
 
  public Scenario endroit() {
    iterateur = liste.listIterator();
    return this;
  }
 
  public Scenario envers() {
    iterateur = new InverseListIterator(liste); // Définit l'implémentation inversée
    return this;
  }
 
  public Scenario next(E element) {
    Assert.assertEquals(element, iterateur.next());
    return this;
  }
 
  public Scenario hasNoNext() {
    Assert.assertFalse(iterateur.hasNext());
    return this;
  }
 
  public Scenario nextIndex(int index) {
    Assert.assertEquals(index, iterateur.nextIndex());
    return this;
  }
 
  public Scenario previous(E element) {
    Assert.assertEquals(element, iterateur.previous());
    return this;
  }
 
  public Scenario hasNoPrevious() {
    Assert.assertFalse(iterateur.hasPrevious());
    return this;
  }
 
  public Scenario nextPrevious(int index) {
    Assert.assertEquals(index, iterateur.previousIndex());
    return this;
  }
 
  public Scenario add(E element) {
    iterateur.add(element);
    return this;
  }
 
  public Scenario remove() {
    iterateur.remove();
    return this;
  }
 
  public Scenario checkList(E... elements) {
    Assert.assertEquals(Arrays.asList(elements), liste);
    return this;
  }
}

Et un petit exemple d'utilisation :

Code Java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
class InverseListIterator {
  @Test
  public void testEndroit() {
    new Scenario<String>("a", "b")
      .endroit().next("a").next("b").hasNoNext()
      .endroit().add("c").next("a").next("b").hasNoNext()
      .checkList("c", "a", "b");
  }
  @Test
  public void testEnvers() {
    new Scenario<String>("a", "b")
      .envers().next("b").next("a").hasNoNext()
      .envers().add("c").next("b").next("a").hasNoNext()
      .checkList("a", "b", "c");
  }
}

Bonjour Nemek,

Merci pour ton exemple qui est un cas d'utilisation possible.
Je me rappelle avoir lu une proposition en ce sens mais ne me souviens plus ou.
L'un des avantages de cette solution est de pouvoir chaîner les vérifications à la manière de ce que fait AssertJ (anciennement FEST Assert) via les Asserter (voir la fin de cet article).