www.infkoffler.com - Site de cours d'informatique

Accueil

Java Standard Edition

Java EE 5

Visual Basic .Net 2005

Cours Javascript - DOM - DHTML

Nouveautés sur le site

Contacts

Accueil > Java Standard Edition > Les collections(4): AbstractList(java.util)

____________________________________________________________________________________________________

Connexion

Les collections(4): AbstractList(java.util)

Sommaire :

I) Généralités
II) Les méthodes abstraites à implémenter
III) Les autres méthodes à implémenter éventuellement
IV) L'itérateur: la classe interne privée Itr
   IV.1) Les attributs privés de Itr
   IV.2) Les méthodes public de Itr
(Suite dans une autre page)
V) La classe interne non static private ListItr, dans la classe AbstractList
VI) La classe SubList<E>, dans le même fichier que AbstractList
VII) La classe RandomAccessSubList<E>(même fichier que AbstractList), et l'interface RandomAccess (java.util)
   VII.1) L'interface RandomAccess (java.util)

I) Généralités

En résumé, AbstractList est une implémentation minimale de l'interface List, mais pour les listes qui ont une structure de données à accès aléatoire( comme un tableau). Sinon, si les données internes sont en accès séquentiel(comme pour une liste chaînée), utiliser AbstractSequentialList.
Pour les listes non modifiables, tout est basé sur get(int index), et size(). Il faudra juste implémenter ces méthodes.
Pour les listes modifiables, tout est basé sur la méthode set(int index, Object element), qu'il faudra donc implémenter. Et pour les listes qui sont aussi redimensionnables, la classe se base sur add(int index, Object element), et remove(int index), qu'il faudra redéfinir( à la base, elles ne déclenchent que UnsupportedOperationException).
Au contraire notamment de AbstractCollection, il n'est pas nécessaire de fournir un itérateur. Un itérateur(et un list iterator) est fourni, qui est basé ici sur les méthodes d'accès aléatoires.
Pour les méthodes déjà implémentées, il est parfois possible de donner une implémentation plus efficace.
La classe est générique. Elle hérite de AbstractCollection, que nous avons déjà vue( qui elle-même implémente Collection). Enfin, la classe implémente l'interface List<E>, qui elle-même étend l'interface Collection<E>. Toute la partie minimale d'implémentation concernant la partie de List qui hérite de Collection, est implémentée par AbstractCollection, c'est pour cela qu'on en hérite.
AbstractList s'occupe du reste de List.

II) Les méthodes abstraites à implémenter

Retourne l'élément qui est à l'index indiqué.

Remarque: il y aura une méthode abstraite venant de AbstractCollection, la méthode size(), qui sera à implémenter également.

III) Les autres méthodes à implémenter éventuellement

Voici les méthodes optionnelles, qui ne font que déclencher une UnsupportedOperationException, et qui sont à redéfinir.

si la liste est modifiable:
si la liste est redimensionnable:

IV) L'itérateur: la classe interne privée Itr

La méthode iterator() utilise la classe interne non-statique privée Itr. On remarque qu'il y a une méthode iterator() qui retourne un Iterator, malgré qu'on peut obtenir aussi un ListIterator avec listIterator().

private class Itr implements Iterator<E> {
	/**
	 * Index of element to be returned by subsequent call to next.
	 */
	int cursor = 0;

/**
	 * Index of element returned by most recent call to next or
	 * previous.  Reset to -1 if this element is deleted by a call
	 * to remove.
	 */
	int lastRet = -1;

/**
	 * The modCount value that the iterator believes that the backing
	 * List should have.  If this expectation is violated, the iterator
	 * has detected concurrent modification.
	 */
	int expectedModCount = modCount;

public boolean hasNext() {
            return cursor != size();
	}

public E next() {
            checkForComodification();
	    try {
		E next = get(cursor);
		lastRet = cursor++;
		return next;
	    } catch (IndexOutOfBoundsException e) {
		checkForComodification();
		throw new NoSuchElementException();
	    }
	}

public void remove() {
	    if (lastRet == -1)
		throw new IllegalStateException();
            checkForComodification();

try {
		AbstractList.this.remove(lastRet);
		if (lastRet < cursor)
		    cursor--;
		lastRet = -1;
		expectedModCount = modCount;
	    } catch (IndexOutOfBoundsException e) {
		throw new ConcurrentModificationException();
	    }
	}

final void checkForComodification() {
	    if (modCount != expectedModCount)
		throw new ConcurrentModificationException();
	}
    }

Nous avons vu, dans le chapitre sur l'interface Collection, que pour l'implémentation de Iterator, qu'on peut trouver dans AbstractList (java.util), on voit qu'il a été choisi une classe(private) interne non statique. C'est à dire que chaque objet Iterator nécessitera un objet AbstractList pour pouvoir être instancié, et aura accès à tous ses attributs et méthodes. L'objet Iterator aura ici accès aux méthodes d'obtention d'un élément de la collection.

IV.1) Les attributs privés de Itr

L'attribut friendly cursor est l'index de l'élément qui sera retourné lors du prochain appel à la méthode next.
Plus classique, cet attribut pointe sur l'index courant, c'est à dire l'index qui a été retourné par le dernier appel à next ou à previous.
expectedModCount permet de détecter les modifications concurrentes

IV.2) Les méthodes public de Itr

Rappelons que Itr implémente Iterator<E>.
La méthode publique next() appelle d'abord la méthode checkForComodification() qui va déclencher une exception s'il y a eu modification concurrente.
next() est basé sur la méthode get(int index) de l'objet AbstractList rattaché à l'objet Itr(n'oublions pas que Itr est une classe interne non statique). Donc next() appelle get, avec cursor en paramètre, elle demande l'objet dont l'index est celui qu'on a calculé pour le prochain next. Puis elle met à jour lastRet, en lui donnant la valeur de cursor. Et enfin, mise à jour de cursor, en l'incrémentant de 1. En cas d'exception IndexOutOfBounds du get, c'est pas normal, alors on se demande s'il n'y a pas eu de modification concurrente, puis on retourne, à coup sûr, une NoSuchElementException( java.util).
hasNext retourne false uniquement si cursor dépasse la fin de la collection.
remove() de Itr, utilise remove(index) de l'objet rattaché AbstractList. remove() supprime l'élément "courant", c'est-à-dire le dernier élément retourné par next ou previous.
Si lastRet( qui est l'index de cet élément courant)==-1, on déclenche une IllegalStateException(java.lang) (exception liée à un état illégal).
Au début de remove(), on vérifie qu'il n'y a pas eu de modification concurrente.
Puis on efface l'élément avec le remove(index), de l'objet AbstractList rattaché.
On met à jour cursor, en le décrémentant de 1: en effet, le prochain obtenu par next, sera diminué de 1, puisqu'on a l'élément courant toujours inférieur à cursor. On remarque le test "if (lastRet<cursor)", qui normalement est toujours vrai, qui sert à s'assurer de l'intégrité des indexs.
Puis on met lastRet à -1. Et enfin on met à jour expectedModCount.

V) La classe interne non static private ListItr, dans la classe AbstractList
VI) La classe SubList<E>, dans le même fichier que AbstractList
VII) La classe RandomAccessSubList<E>(même fichier que AbstractList), et l'interface RandomAccess (java.util)
VII.1) L'interface RandomAccess (java.util)

RETOUR HAUT