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;
	}
 
}