Générics et découpage de collections

Version imprimable

bonjour à tous,

je voudrais créer une fonction qui découpe une collection en en plusieurs sous collection de taille fixe, du style :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
 
List<String> list = new ArrayList<String>();
 
//opérations sur la listes (add, ...)
 
 
List<List<String> listeDecoupee= decoupage(list, 5);
 
//parcours pour afficher tous les elements
for(List<String> subList : list) {
    for(String str : subList) 
       sysout(str)
}

pour l'instant si je n'utilise que des List ça fonctionne impec avec ça :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
public static <T> List<List<T>> splitIntoChunks(List<T> list, int chunkSize) {
		if (chunkSize <= 0)
			throw new IllegalArgumentException("chunkSize must be greater than 0.");
 
		List<List<T>> retVal = new ArrayList<List<T>>();
 
		int index = 0;
 
		while (index < list.size()) {
			int count = list.size() - index > chunkSize ? chunkSize : list.size() - index;
			retVal.add(list.subList(index, index+count));
 
			index += chunkSize;
		}
 
		return retVal;
	}

j'aimerais donc généraliser ça pour tout type de collection genre

Code:

1
2
3
4
5
6
Set<UUID> set = new HashSet<UUID>();
 
//opérations quelconques ( ...)
 
 
Set<Set<UUID> decoupee= decoupage(set, 20);

14/01/2011, 15h48
Alkhan

bonjour,

Je ne comprend pas vraiment le problème ?
Il suffit de remplacer List par Collection et voila !
14/01/2011, 16h28
Spidy

justement je voudrais garder le type de collection passé en argument.

si on passe une List<String> ça renvoi une List<List<String>
14/01/2011, 16h55
billynirvana

Passer en Collection ne suffira pas car la méthode list.subList() est propre aux java.util.List.

De même, il y a pas de subList pour les Set ^^.

Par ces arguments il est donc impossible de généraliser. Et je doute que ce soit réalisable même en modifiant le contenu de splitIntoChunks.
14/01/2011, 16h59
Alkhan
en fait, j'avais pas fait attention, mais je pense que tu va avoir du mal à généraliser.
La cause est ceci :
Code:

1 2 list.subList(index, index+count)
Le sublist est un peu particulier et en plus n'existe pas sur les collections mais uniquement sur les List. Et je doute que tu arrives a avoir équivalant sur les "Set" et autres collections.

Edit : ah grillé de peu :)

Et si tu fais un truc du genre

Code:

1
2
3
4
5
6
7
8
9
 
public class Splitter<T extends Collection<V>, V extends Collection<String>> {
 
	public T decoupage(V list,int chunkSize){
                //balbla
		return null;
	}
 
}

par contre tu peux pas utiliser des fonctions statiques pour ça

J'ai pondu du code rapidement sans tester mais rien ne me semble impossible :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
	public static <T> Collection<Collection<T>> splitIntoChunks(Collection<T> collection, int chunkSize) {
		if (chunkSize <= 0)
			throw new IllegalArgumentException(
					"chunkSize must be greater than 0.");
 
		Collection<Collection<T>> retVal = new ArrayList<Collection<T>>();
		Collection<T> col = null;
 
		int index = 0;
 
		for (T t : collection) {
			if(index%chunkSize == 0){
				col = collection.getClass().newInstance();
				retVal.add(col);
			}
			col.add(t);
			index++;
		}
 
		return retVal;
	}

Pas forcement ce qu'il y a de plus performant mais ca doit marcher

14/01/2011, 17h22
Alkhan

Citation:

Envoyé par Mobius

Pas forcement ce qu'il y a de plus performant mais ca doit marcher

Eh non ca ne marche pas, car ce ne sont pas des vues de la collection d'origine. Par conséquent, si tu modifie la collection d'origine ca ne sera pas répercuté dans la collection découpé, et inversement bien sur.
14/01/2011, 17h38
Mobius

Citation:

Envoyé par Alkhan

Eh non ca ne marche pas, car ce ne sont pas des vues de la collection d'origine. Par conséquent, si tu modifie la collection d'origine ca ne sera pas répercuté dans la collection découpé, et inversement bien sur.

Effectivement :oops: j'ai lu un peu trop vite.

Dans ce cas, je rejoins l'avis que ce n'est pas faisable. Pour moi ca n'a même pas vraiment de sens pour les Set notamment.

Si on cherche a faire des vues pour les Set, on pourrait chercher a rajouter un element dans un sous-ensemble. Que se passe il si l'élément est présent dans l'ensemble principal ? Si l'élément n'est pas présent dans l'ensemble principal, tout va bien. Si l'élément est présent mais qu'il ne l'ai pas dans le sous ensemble, on a un problème...
14/01/2011, 17h49
super_toinou

Je sais pas si c'était la problématique initiale.

Mais totalement d'accord, une modif n'impactera pas la liste d'orgine (a moins que les sous Collections soient codées à la main et aient la référence sur la collection d'origine. Mais là c'est moche).

ça, ça à l'air de marcher :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 public static <T> Collection<? extends Collection<T>> chunk(Collection<T> target, int chunkSize) throws InstantiationException, IllegalAccessException { if (chunkSize <= 0) throw new IllegalArgumentException("chunk size must be greater than 0."); Collection<Collection<T>> filler = new ArrayList<Collection<T>>(); Iterator<T> itTarget = target.iterator(); Collection<T> sub = null; int index = 0; while(itTarget.hasNext()) { if(index%chunkSize == 0) { sub = target.getClass().newInstance(); filler.add(sub); } while(itTarget.hasNext() && index++ < chunkSize) sub.add(itTarget.next()); index = 0; } return filler; }
oui forcément le subList pouvait pas marché :mrgreen: mais mon problème demeure car ça retourne une Collection et pas le même type de collection que l'argument.

d'ailleurs

Code:

sub = target.getClass().newInstance();

sort un warning.

@toinou : je pense pas que ça change quelque chose car le paramètrage ce fait sur la méthode et toi c'est au niveau de la classe.

sinon il y a ça (la collection qui sera remplie est en 2e paramètre :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
public static <T, U extends Collection<T>, V extends Collection<U>> void chunk(U target, V filler, int chunkSize) throws InstantiationException, IllegalAccessException {
		if (chunkSize <= 0)
			throw new IllegalArgumentException("chunk size must be greater than 0");
 
		Iterator<T> itTarget = target.iterator();
		U sub = null;
		int index = 0;
 
		while(itTarget.hasNext()) {
			if(index%chunkSize == 0) {
				sub = (U) target.getClass().newInstance();
				filler.add(sub);
			}
 
			while(itTarget.hasNext() && index++ < chunkSize) 
				sub.add(itTarget.next());
 
			index = 0;
		}
	}

mais toujours un warning sur le newInstance()

Le warning sera toujours là, à cause de la nature des génériques en Java.

En résumé le compilateur, trop généraliste, ne peut pas garantir que target.getClass().newInstance() va bel et bien produire un U. Il sait que ça va produire un objet qui étend Collection, mais ne sait pas si le type de cet objet sera qualifiable comme U.
D'ailleurs, il est possible de faire qu'il ne le soit pas.

Un truc que tu pourrais faire, c'est définir une méthode statique :
Code:

1 2 3 4 5 6 7 8 9 10 public static <T, U extends Collection<T>> U newCollection(U col) throws InstantiationException, IllegalAccessException { @SuppressWarnings("unchecked") U c = (U)col.getClass().newInstance(); if(!c.isEmpty()) { throw new IllegalArgumentException( "Collection class " + col.getClass().getName() + " builds non-empty instances with default constructor. " + "This violates type-safety on the Collection parameter, we therefore fail here instead of randomly anywhere."); } return c; }
et t'en servir pour construire une nouvelle collection de même type qu'une collection donnée.

Cette méthode s'occupe de vérifier les garanties de type que le compilateur se plaint de ne pas pouvoir vérifier. (Au prix d'échouer chaque fois qu'on lui demande de créer une Collection dont le constructeur par défaut construit une Collection qui contient déjà des éléments.)

16/01/2011, 11h12
Spidy

oui ça à l'air d'être une bonne façon, mais ce que je comprends pas c'est le fait qu'une nouvelle instance ne soit pas vide.

ça fonctionnerai pas avec un try catch de classcastexception ou même exception tout court??
16/01/2011, 11h36
thelvin

Citation:

Envoyé par Spidy

oui ça à l'air d'être une bonne façon, mais ce que je comprends pas c'est le fait qu'une nouvelle instance ne soit pas vide.

Les Collection fournies avec Java sont toujours vides quand construites avec le constructeur par défaut.
Mais rien n'empêche d'en implémenter de nouvelles, qui font autrement. Dans ce cas-là, elles ont leur propre logique de type-safety, qui ne correspond pas à ce qu'on attend.

Citation:

Envoyé par Spidy

ça fonctionnerai pas avec un try catch de classcastexception ou même exception tout court??

Non. Le problème avec la violation de type-safety, c'est qu'elle produit des ClassCastException ailleurs que là où elle est créée. À un moment plus tard.
Et cela complique pas mal le débuggage. C'est pourquoi on essaie autant que possible de forcer le lancement de l'Exception là où l'erreur arrive. C'est encore mieux quand une erreur ne peut pas arriver, bien sûr.

Salut,

Quelques remarques :
Dans le tout premier code on utilise subList(). Il faut faire très attention au fait que la liste ainsi créée est très lié à la liste d'origine, et surtout qu'il s'agit d'une vue temporaire qui sera invalide si on modifie la liste d'origine par la suite...
Le newInstance() peut sembler correct, mais posent d'autres en plus des problèmes déjà signalés.
En effet cela marche bien avec les collections de base (ArrayList, HashSet, ...), mais même dans l'API on retrouve plusieurs collections qui ne possède pas de constructeur vide. C'est ainsi le cas de la plupart des collection crée via les fabriques de la classe Collections/Arrays ou de ceux retournées via les méthodes subList() ou autres...
Par exemple ce code pourtant banal génère une exception :
Code:

1 2 List<String> list = Arrays.asList("a","b","c","d","e","f","g","h","i"); Collection<? extends Collection<String>> chunks = chunk(list, 5);
Car Arrays.asList() retourne un type privé sans constructeur vide.
A mon avis une version retournant un type fixe est amplement suffisant (après je n'ai pas vraiment compris les besoins exact de faire tous cela donc cela peut m'échapper).
Bref cela donnerais quelque chose comme cela :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 public static <E> List<List<E>> splitIntoChunks(Collection<E> coll, int chunkSize) { if (chunkSize <= 0) throw new IllegalArgumentException( "chunk size must be greater than 0."); final List<List<E>> result = new ArrayList<List<E>>(); List<E> current = null; int count = 0; for (E element : coll) { if (count==0) { current = new ArrayList<E>(chunkSize); result.add(current); } current.add(element); count = (count + 1) % chunkSize; } return result; }
a++

16/01/2011, 19h48
Spidy

le fait d'avoir des warning (ou de bidouiller le code pour pas en avoir) me plait pas du tout donc je pense que je vais prendre ta solution.

Code:

new ArrayList<E>(chunkSize);

pas con du tout d'initialiser à la bonne taille :ccool:

pour subList() ça fonctionne qu'avec des list donc de toute façon j'aurais pas pu l'utiliser.