Discussion :

[Iphelias]

Bonjour au bureau aujourd'hui on a eu un petit débat et j'avoue que personne n'a la même approche concernant ce point.

Voici 2 implémentation qui font la même chose.
Pourriez vous m'éclairer sur ce qui doit être utilisé et pourquoi.

SOLUTION 1

Code :

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

1
2
3
4
 
	private void sortedList(List<Item> unsortedList, List<Item> sortedLiest){
		//blabla
	}

SOLUTION 2

Code :

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

1
2
3
4
5
6
 
	private List<Item> sortedList(List<Item> unsortedList){
		List<Item> sortedList = new ArrayList<Item>();
		//blabla
		return sortedList;
	}

Ne prenez pas cet exemple simpliste au pied de la lettre. C’était juste pour avoir un cas concret.

Merci par avance.

[JoeChip]

Perso j'évite les void, au pire je renvoie this, ce qui permet de chaîner les instructions. De plus dans ton exemple, ça permet de travailler sur la liste sans modifier la liste source,ce qui permet une meilleure réutilisation.

[Iphelias]

Merci JoeChip pour ton retour.
Tu vas dans mon sens donc je valide !

[JoeChip]

En plus j'avais mal lu la source, mais je ne vois pas pourquoi envoyer en paramètre quelque chose qu'on veut obtenir en retour... Sémantiquement c'est absurde. Le boulot de la méthode c'est de renvoyer la liste triée, donc le void se justifie encore moins que d'habitude...

[thelvin]

Edit : oui, je répète ce qui est dit dans le post juste au-dessus -_-°. Il a été posté entre-temps

Personnellement mon raisonnement s'arrête ailleurs : la méthode 1 oblige à fournir une List en paramètre alors que c'est elle qui décide de ce que cette liste doit contenir.
C'est pas clair du tout. Ça peut être une solution dans le cas où il faut pouvoir s'adapter à n'importe quelle implémentation de List, mais à part ça c'est confus. (Et ce n'est pas une raison pour ne pas renvoyer la List une fois que sa construction a été achevée.)