Collections: Interface et Objet

**dynek** · 04/04/2007, 09h06

Bonjour,

Je suis entrain de lire de la documentation sur les collection et map.

J'ai une question concernant les interfaces.

Quel est l'avantage de faire:
Collection<String> collection = new ArrayList<String>();

Plutôt que:
ArrayList<String> collection = new ArrayList<String>();

Et surtout quelle est la différence ?

Je pose cette question parce que j'ai vu:
List<Produit> produits = new ArrayList<Produit>();

Pourquoi utiliser List plutôt que ArrayList ?

Merci beaucoup pour votre temps!

**afrikha** · 04/04/2007, 09h10

Bonjour,

Le fait de passer par les interfaces permet d'être libre vis à vis de l'inplémentation de la structure de données : en effet supposons qu'après coup tu as décidé d'utiliser une LinkedList au lieu d'une ArrayList, tu n'as qu'une seule ligne à changer c'est :

Code :

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

List<Produit> produits = new LinkedList<Produit>();

Tout le reste du code reste inchangé.

J'espère que c'est clair, dans le cas contraire n'hésite pas à poser des questions

@+

**dynek** · 04/04/2007, 09h35

Salut,

Merci pour ta réponse.

Cependant je ne comprends pas encore très bien.
Qu'est-ce que ça changerait dans le code si je définissais à l'avance:
ArrayList<String> = new ArrayList<String>();

Et que je veuille ensuite changer par une LinkedList. Je change les 2 ArrayList en LinkedList et c'est tout bon.

Donc je ne vois pas d'avantage.

Merci pour ton temps

**adiGuba** · 04/04/2007, 10h12

Salut,

Cela permet en effet de faire abstraction de l'implémentation.

Grosso modo lorsque tu déclares :

Code :

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

ArrayList<String> collection;

Tu utilises une liste d'objet indexé, basé en interne sur l'utilisation d'un tableau d'objet.

Code :

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

List<Produit> produits;

Tu utilises une liste d'objet indexé (quel que soit son implémentation).

Code :

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

Collection<Produit> produits;

Tu utilises une collection d'objet (quel que soit son implémentation).

Les interfaces décrivent le comportement général des collections. Pour rappel, les principales interfaces de l'API de collections :

Collection représente un ensemble d'élément.
List représente un ensemble d'élément ordonné indexé.
Set représente un ensemble d'élément unique.
Map permet d'associer une clef à une valeur.
Queue et BlockingQueue (Java 5.0) représentent des queues qui ordonne les éléments (généralement en FIFO ou en LIFO)
Deque et BlockingDeque (Java 6) sont des queues permettant l'insertion et la suppression à leurs deux extrémités.

Ensuite chaque implémentation a ses spécificités propre, dont le choix peut dépendre de besoins préçis.

Mais dans la plupart des cas tu n'as pas besoin d'utiliser une implémentation en particulier, et l'utilisation d'une interface à la place du type réel te permet une plus grande souplesse. C'est vrai en particulier pour les paramètres et types de retour des méthodes.

En effet prenons un cas particulier d'une méthode qui affiche tous les éléments d'une ArrayList :

Code :

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

1
2
3
4
5
	public static void printAll (ArrayList<?> arrayList) {
		for (Object o : arrayList) {
			System.out.println(o);
		}
	}

Le problème est que tu limites "virtuellement" l'utilisation d'ArrayList alors qu'en utilisant une interface tu permets l'utilisation de la méthode avec n'importe quel type :

Code :

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

1
2
3
4
5
	public static void printAll (Collection<?> c) {
		for (Object o : c) {
			System.out.println(o);
		}
	}

Bref tu ne limites plus l'utilisateur de ta méthode à utiliser une seule implémentation, mais tu lui permet d'utiliser n'importe laquelle...

Autre exemple, où là tu t'imposes une seule implémentation. Imaginons que dans une de tes classes tu ais une méthode du style :

Code :

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

1
2
3
4
5
	private ArrayList<String> data = new ArrayList<String>();
 
	public ArrayList<String> getData() {
		return this.data;
	}

Maintenant si ta classe évolue et que tu te retrouves dans l'obligation d'utiliser une autre type de liste (par exemple une liste syncronized), tu es obligé de modifier le type de retour de ta méthode getData(), et par la même potentiellement tout les codes qui utilisent ta méthode (bref tu fais une modifications qui casse la compatibilité source et binaire). Ce qui peut se reveler assez génant (en particulier si tu n'as pas la main sur tout le code).

Alors que si dès le départ tu aurais fait abstraction de l'implémentation de ta liste :

Code :

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

1
2
3
4
5
	private List<String> data = new ArrayList<String>();
 
	public List<String> getData() {
		return this.data;
	}

Ce changement aurait été totalement transparent :

Code :

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

1
2
3
4
5
	private List<String> data = Collections.synchronizedList(new ArrayList<String>());
 
	public List<String> getData() {
		return this.data;
	}