Confusion sur le design pattern composite

Version imprimable

Bonjour,
Je suis entrain de voir le design pattern Composite.J'ai compris le principe et j'ai suivi un exemple d'un semi remorque composé d'un tracteur et d'une remorque, qui ont un poids séparé mais également un poids camion entier. Un tracteur routier doit également pourvoir rouler sans remorque.

Pour la classe composite j'ai trouvé deux méthodes que j'ai vraiments pas compris getEnfant() et getPoid():

Code:

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
 
public class CamionComposite implements Composant {
 
	private Collection children;
 
    public CamionComposite() {
        children = new ArrayList();
    }
 
 
    public void add(Composant composant){
 
        children.add(composant);
    }
 
 
    public void remove(Composant composant){
        children.remove(composant);
    }
 
    public Iterator getChildren() {
        return children.iterator();
    }
 
	@Override
    public int getPoids() {
        int result = 0;
        for (Iterator i = children.iterator(); i.hasNext(); ) {
            Object objet = i.next();
 
            Composant composant = (Composant)objet;
 
            result += composant.getPoids();
        }
        return result;
    }
}

J'ai fais la méthode getPoids avec ma propre manière et sa fonctionne mais j'ai vu que de nombreuse code sources utilise Iterator j'aimerais comprendre le principe

voila mon code :

Code:

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
package CompositeCamion;
 
import java.util.ArrayList;
import java.util.Collection;
import java.util.Iterator;
 
public class CamionComposite extends Composant {
public ArrayList<Composant> enfants = new ArrayList<Composant>();
	public CamionComposite()
	{
 
	}
 
	public void ajouter(Composant composant)
	{
		enfants.add(composant);
	}
	public void supprimer(Composant composant)
	{
		enfants.remove(composant);
	}
	@Override
	public int getPoids() {
		int resultat=0;
		for(Composant composant:enfants)
		{
			resultat += composant.getPoids();
		}
		return resultat;
	}
	public Iterator getEnfant()
	{
		return enfants.iterator();
	}
 
}

Merci

16/02/2020, 19h49
joel.drigo
Salut,

Un iterator est un design pattern qui définit un moyen d'obtenir successivement (traverser) les éléments contenus dans un conteneur, comme une java.util.Collection, ou une java.util.List (qui n'est qu'une java.util.Collection particulière).

Dans le JDK, on a a disposition l'interface java.util.Iterator qui permet de définir un iterator. On a également l'interface java.lang.Iterable qui décrit une classe qui a une méthode Iterator iterator(), une méthode donne qui retourne un iterator, logiquement pour obtenir successivement des composants de l'instance représentée par cette classe.

En JavaSE 5 a été introduit la syntaxe dite du for-each. Cette syntaxe permet :
1. D'obtenir successivement les composants d'un tableau afin, sans passer par for classique sur les index
2. D'obtenir successivement les composants d'un Iterator d'une instance de classe implémentant Iterable.
Lorsque tu écris :
Code:

1 2 for(Composant composant:enfants) { }
tu utilises la syntaxe for-each qui n'est qu'une simplification syntaxique de l'équivalent du parcours par l'Iterator sur l'ArrayList enfants, qu'on aurait pu écrire (et qu'avant Java 5, on aurait forcément écrite, auxgenerics près) comme ça :

Avec un for
Code:

1 2 3 for(Iterator<Composant> iterator = enfants.iterator(); iterator.hasNext(); ) { Composant composant = iterator.next(); }
ou avec un while :
Code:

1 2 3 4 Iterator<Composant> iterator = enfants.iterator(); while( iterator.hasNext() ) { Composant composant = iterator.next(); }
17/02/2020, 16h02
dibax10

Salut,

Merci pour les explications. Donc ce que j'ai écris est correct? car je trouves que c'est très compliqué le code utilisant Iterator et de plus pour le diagramme spécifique au design pattern composite on doit implémenté la méthode getEnfant() ne pas l'utiliser ne pose donc pas de problème?
19/02/2020, 12h20
joel.drigo
1. Indépendamment de la notion de composite, la syntaxe Java évolue en Java5 pour introduire le for-each, une boucle for qui permet d'itérer sur un ensemble de valeurs.
  Le principe est qu'on peut utiliser le for-each, sur :
  1. un tableau
    
    Code:
    
    1 2 3 4 int[] array = {1,2,3}; for(int i : array) { // for-each sur un tableau // successivement, i vaut 1, puis 2, puis 3 }
  2. une instance de classe implémentant Iterable, une interface dont la méthode iterator() retourne un Iterator
    
    Code:
    
    1 2 3 4 List<String> list = Arrays.asList("a","b","c"); for(String s : list) { // for-each sur un Iterable<String> // successivement, s vaut "a", puis "b", puis "c" }
  Cette syntaxe a été introduite pour simplifier justement la forme de boucle qu'on aurait été obligé d'écrire avant (en plus sans disposer des types paramétrés) :
  Code:
  
  1 2 3 for(Iterator iterator = list.iterator(); iterator.hasNext(); ) { String s = (String)iterator.next(); }
  Ou par un while :
  Code:
  
  1 2 3 4 Iterator iterator = list.iterator(); while(iterator.hasNext()) { String s = (String)iterator.next(); }
  Ce n'est pas vraiment plus compliqué, juste plus long, plus verbeux.
  A noter que pour faire de la suppression, on n'est toujours obligé d'utiliser un Iterator :
  Code:
  
  1 2 3 4 5 6 for(Iterator<String> iterator = list.iterator(); iterator.hasNext(); ) { String s = iterator.next(); if ( "aeiouy".indexOf(s)>=0 ) { iterator.remove(); } }
  Donc pour répondre à ta question, ce n'est pas incorrect d'utiliser un for-each au lieu de la forme complète par Iterator. Au niveau exécution, ça fera la même chose. Il y'a même de fortes chances que le bytecode soit le même, en toute logique.
2. Du point de vue de la cohérence, ce n'est pas tant au niveau de for-each vs usage de Iterator, mais sur le fait d'appeler iterator() sur la variable locale (qui au passage devrait être privée, sinon, accès direct possible), plutôt que de passer par la méthode iterator() de CamionComposite. Les résultats peuvent être différents en cas d'extension de la classe, et de redéfinition de méthode (dans ton cas on continue d'itérer sur la variable alors que la méthode iterator() peut avoir été redéfinie de telle manière que passer par getPoids() ou recalculer le poids() par iterator() peut donner des résultats différents donc incohérents. On peut également faire des suppressions via la méthode iterator() sans passer par la méthode "supprimer", et ça peut également mettre la stabilité de l'instance en défaut.
3. Du point de vue du design pattern, il y a matière à débat amha. Le design pattern ne parle absolument pas d'itérateur qui est moyen tecnique de convenience pour moi, mais de pouvoir accèder aux enfants du composite. Le design pattern de ce point de vue est assez vague, avec une méthode getChild, qui ne définit pas si on accède à chaque enfant séparément, ou si on obtient une collection, ou autre chose. Une opération agrégante de la composition (cumul, réduction...) n'est pas spécialement non plus imposée. Avec un composite qui représente une arborescence de systèmes de fichiers, on peut avoir avoir une opération qui donne la date qui n'est pas une réduction des dates des composants, mais propre au composite, ou la date la plus récente parmi tous les composants, ou une opération qui donne la taille, qui peut être la somme des tailles des composants, ou une manière complètement différente d'évaluer la taille globale (par rapport à des notions de blocs, secteurs, etc..., ou autre chose...)
20/02/2020, 16h54
dibax10

Donc vaux mieux d'utiliser Iterator() pour éviter toutes incohérence

Merci pour toutes les explications fournies. Toujours la pour me sauver la vie :D