Discussion :

[nouilletonne]

Bonjour

En fait si on ne parle de pas de java au départ mais sur :

Les structures de données :

- tableau : taille fixe en java considéré comme un objet de type générique ou primaire

- liste : une suite finie de données de même type donc comme un tableau mais avec une définition récursive :

- soit vide
- soit la juxtaposition d’un premier élément et une autre liste :

- représentée par un tableau donc limité avec des indices pour le premier element et l'autre liste= listes contigues

- référencé par un pointeur juste après le premier élement = listes chainées

- piles et files : sont elles des listes particulières et donc utilisable avec ou sans tableau ? mais peut-être que je me trompe là

car seul les piles sont souvent présentées avec des listes (donc avec ou sans tableau) et les files avec juste un tableau, je n'ai pas encore essayé mais pourquoi ne pourraient elles pas avec une liste chainée ?

Mais comme en Java sur ce diagramme :

http://www.codejava.net/images/artic...20overview.png

les files sont appelés Queue ok. mais comme sur ce diagramme où l'on voit pas par contre que Stack hérite de Vector qui serait les piles. que LinkedList, associés au listes chainées, hérite de Deque et de List. par contre Queue est une classe seule (juste Collections ) mais celà voudrait dire qu'une file n'est pas une liste alors que c'est très souvent présenté comme une liste plus restrictive comme pour les piles.

J'avoue que je m'y perd. J'ai essayé d'être clair sur mes interrogations.

En tout cas merci si quelqu'un arrive à me clarifier les choses

[kolodz]

Ce qu'il faut bien comprendre quand tu regarde ce schéma, c'est qu'une grande partie sont seulement des constructions abstraites.

Si on prends l'exemple de ta classe Stack. Celle-ci hérite de Vector, pour ajouter le comportement d'une LIFO.

The Stack class represents a last-in-first-out (LIFO) stack of objects.

Il se trouve qu'il ne faut pas grand chose pour avoir le comportement d'une LIFO à partir de la classe Vector :

The Vector class implements a growable array of objects.

En fait, il suffit de manipuler correctement ton tableau pour avoir le comportement d'une LIFO.
D'ailleurs si tu regarde le code de la classe Stack, c'est seulement cela que tu verra :

Code :

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

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
38
39
40
41
42
public
class Stack<E> extends Vector<E> {
 
    public Stack() {
    }
 
    public E push(E item) {
        addElement(item);
 
        return item;
    }
 
    public synchronized E pop() {
        E       obj;
        int     len = size();
 
        obj = peek();
        removeElementAt(len - 1);
 
        return obj;
    }
 
    public synchronized E peek() {
        int     len = size();
 
        if (len == 0)
            throw new EmptyStackException();
        return elementAt(len - 1);
    }
 
    public boolean empty() {        return size() == 0;
    }
 
    public synchronized int search(Object o) {
        int i = lastIndexOf(o);
 
        if (i >= 0) {
            return size() - i;
        }
        return -1;
    }
}

Donc la classe Stack est basé sur la classe Vector, car celle-ci fait déjà le plus gros du travail pour nous. Stack n'ajoute qu'une petite partie de comportement sur la manipulation.

Du coup, pourquoi la classe Vector hérite de la classe AbstractList ?

La classe Vector implémente l'interface List. Or Il se trouve que la classe abstrait AbstractList est là pour "facilité la vie" de toutes implémentations de l'interface List. (Car, il n'y a pas de code/comportement dans une interface).
Du coup, il y a la classe AbstractList !

This class provides a skeletal implementation of the {@link List} interface to minimize the effort required to implement this interface backed by a "random access" data store (such as an array).

En gros, c'est un facilitateur :

Code :

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

1
2
3
4
    public boolean add(E e) {
        add(size(), e);
        return true;
    }

Même si il y a du code un peu complexe dans cette classe, l'idée est bien d'avoir un facilitateur pour un certains nombre de méthode qui ne dépends pas directement de l'implémentation de la liste.

Il y a certains principe de base dans cette structure.

• Les interfaces vont du plus simple au plus compliqué.
• En général, il est fournit une version "Abstraite" d'une interface.
• Et les héritages entre classes, ne se font que pour ajouter du comportement spécifique.

Note :
Pour ce qui est de la liste chainé LinkedList, celle-ci implémente Queue et Deque. Qui sont respectivement la pile (FIFO) et la pile accessible par les deux bouts.
Ce qu’implémente la liste chainé.

Cordialement,
Patrick Kolodziejczyk.

Source :
https://docs.oracle.com/javase/7/doc...tractList.html
https://docs.oracle.com/javase/7/doc...til/Stack.html
https://docs.oracle.com/javase/7/doc...il/Vector.html
http://docs.oracle.com/javase/7/docs...til/Queue.html
http://docs.oracle.com/javase/7/docs...til/Deque.html
http://docs.oracle.com/javase/7/docs...inkedList.html

[nouilletonne]

Merci beaucoup

Juste que dans les cours "théoriques "ça parait être l'inverse :
les piles recrées sont aussi des listes et les files recrées sont souvent implémentées avec des tableaux
en plus d'avoir des lacunes telles en anglais qui me bloque à aller fouiller dans les fiches du site oracle

ce qui m'a amené à poster pour mieux comprendre

de plus souvent c'est peut-etre autre chose mais j'ai du mal à comprendre la différence entre:

Queue<AB<Integer>> q= new LinkedList<AB<Integer>>();
et
LinkedList<AB<Integer>> q= new LinkedList<AB<Integer>>();

[eulbobo]

Queue<AB<Integer>> q= new LinkedList<AB<Integer>>();

Ici, tu définis une Queue q en utilisant les paramètres de l'interface Queue. LinkedList est l'implémentation utilisée (qui implémente Queue via l'interface Deque)
Donc avec q, tu ne pourras utiliser que les méthodes propres à l'interface

LinkedList<AB<Integer>> q= new LinkedList<AB<Integer>>();

Ici, tu définis une LinkedList q utilisant l'implémentation LinkedList. Mais tu pourrais utiliser une autre implémentation héritant de LinkedList
Ici, tu auras accès à toutes les méthodes et propriétés publiques propres à LinkedList, à savoir... Aucune vu que toutes les méthodes publiques utilisables sont décrites dans les interfaces.


C'est plus "propre" de manière générale de travailler avec des interfaces plutôt que des implémentation parce que ça permet de rendre l'usage moins lié à une seule implémentation.
Imagine que tu as la méthode suivante dans une classe :
void doThings(LinkedList<AB<Integer>>)
Que tu utilises comme ceci

Code :

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

1
2
3
 
LinkedList<AB<Integer>> q= new LinkedList<AB<Integer>>();
doThings(q);

Et tu te rends compte que l'implémentation ArrayDeque est vraiment plus intéressante pour toi.... Ben tu ne pourras pas utiliser ta méthode sans changer ton implémentation et ta signature de méthode...
Si maintenant tu as la méthode
void doThings(Queue<AB<Integer>>)

tu n'as qu'a changer l'implémentation utilisée et ça marche !

Code :

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

1
2
3
 
Queue<AB<Integer>> q= new ArrayDeque<AB<Integer>>();
doThings(q);

[Logan Mauzaize]

A noter que Vector et Stack sont déconseillées.

Car elles implémentent des mécanismes de synchronisation qui sont légèrement pénalisants pour les performances et que pour la gestion de la concurrence on peut trouver des structures mieux optimisées. De plus, les "services" offerts par Stack ne font pas l'objet d'une interface et lie donc fortement les APIs à cette classe alors qu'il existe l'inteface Queue et Deque pour abstraire ces comportements.

[nouilletonne]

"Ici, tu définis une LinkedList q utilisant l'implémentation LinkedList. Mais tu pourrais utiliser une autre implémentation héritant de LinkedList
Ici, tu auras accès à toutes les méthodes et propriétés publiques propres à LinkedList, à savoir... Aucune vu que toutes les méthodes publiques utilisables sont décrites dans les interfaces."

j'avoue ne pas bien comprendre. outre le fait que dans les collections java LinkedList semble être la dernière classe donc apart créé une classe fille y'a rien... mais
si LinkedList implémente toutes les méthodes de ses parents je ne pige pas cette phrase :

"Aucune vu que toutes les méthodes publiques utilisables sont décrites dans les interfaces." si elles sont décrites elles sont dans la classe Linkedlist de fait non ? comme si je l'avais créé moi même cette classe ?

après je crois comprendre le reste mais pas sur sur des cas pratiques et l'usage surement mais en tant que débutant on perçoit par les astuces et les obstacles