Implémentation en java de structures de données

Bonjour,
J'aimerais partager avec vous une question qui m'a été posée :

Puisqu'on à disposition en java des structures de données à gogo telles que les listes et les arbres ..., pourquoi trouve -t- on souvent des utilisateurs implémenter eux même des listes à partir de tableaux ou de structures chainées , et des arbres en fabriquant une classe arbre....?

Ma réponse :
Pour avoir une certaine liberté et donc flexibilité au niveau de l'utilisation des méthodes qui ne sont plus de boites noires.

Qu'en pensez vous ?

Je dirais dans un premier jet :

- L'utilisateur n'as pas connaissance qu'il existe une telle structure/fonction déjà présente dans son langage.
- Il veux apprendre. (ce que contient dans la boite noire)
- Il a décider de réinventer la roue a tout prix ^^.

Tout d'abord, merci pour ta réponse.

Citation:

---

L'utilisateur n'as pas connaissance qu'il existe une telle structure/fonction déjà présente dans son langage.

---

En général, ce n'est pas la raison puisqu'il doit se documenter avant tout.

Citation:

---

- Il veux apprendre. (ce que contient dans la boite noire)
- Il a décidé de réinventer la roue a tout prix ^^.

---

Ohouiiii; ce n'est qu'une toute petite riquiqui raison, mais il faut vraiment être motivé!

Je pense vraiment que la raison est la FLEXIBILITÉ d'utilisation des méthodes sur les données. Cela reste mon avis.

Salut,

Citation:

---

Envoyé par wafiwafi

En général, ce n'est pas la raison puisqu'il doit se documenter avant tout.

---

Dans un monde idéal peut-être... mais en pratique c'est rarement le cas !

Citation:

---

Envoyé par wafiwafi

Ohouiiii; ce n'est qu'une toute petite riquiqui raison, mais il faut vraiment être motivé!

---

En tout cas c'est un exercice intéressant ;)

Citation:

---

Envoyé par wafiwafi

Je pense vraiment que la raison est la FLEXIBILITÉ d'utilisation des méthodes sur les données. Cela reste mon avis.

---

Que veux-tu dire exactement ?
Si c'est pour réinventer ce qui existe je n'en vois pas l'intérêt (outre l'exercice justement).


Maintenant si c'est pour bénéficier d'une autre implémentation c'est autre chose...


a++

A mon avis on ne gagne rien en flexibilité concernant les listes.
En revanche concernant l'arbre c'est un concept à part.

Un arbre dispose de méthodes que n'ont pas les listes. Un noeud a généralement une valeur attachée et contient d'autres noeuds. Il peut s'agir d'un noeud racine, d'un noeud normal ou d'un noeud feuille. Un noeud est caractérisé par une profondeur, a éventuellement un père, est rattaché à un et un seul arbre. Un chemin se constitue d'une chaîne de noeud.

Citation:

---

En tout cas c'est un exercice intéressant

---

Oui, c'est vrai.

Citation:

---

Que veux-tu dire exactement ?
Si c'est pour réinventer ce qui existe je n'en vois pas l'intérêt (outre l'exercice justement).

---

Établir sa propre classe et fabriquer ses propres méthodes selon son contexte est tout de même plus souple d'utilisation que faire appel à des méthodes dont on ne connait pas l'implémentation. C'est beaucoup plus pratique également du point de vue étude de complexité. Attention, je ne dis pas qu'il faut tout réinventer mais il arrive que le contexte exige une autre implémentation.

Néanmoins je reste d'accord avec vos réponses!! Cela constitue un très bon exercice et c'est cette raison que dorénavant je retiens.
Merci à vous

Citation:

---

Envoyé par wafiwafi

Établir sa propre classe et fabriquer ses propres méthodes selon son contexte est tout de même plus souple d'utilisation que faire appel à des méthodes dont on ne connait pas l'implémentation.

---

Euh. Dans le cas des structures communes fournies par Java, l'implémentation va un peu de soi quand même.
Et puis, si on veut la connaître, il suffit de la regarder, le code source est facilement affiché dans un EDI. C'est pas franchement indigeste, il y a juste le ConcurrentModificationException fail-early qui complique un peu les choses.

Citation:

---

Envoyé par wafiwafi

C'est beaucoup plus pratique également du point de vue étude de complexité. Attention, je ne dis pas qu'il faut tout réinventer mais il arrive que le contexte exige une autre implémentation.

---

Euh oui, ça arrive, dans certains cas très précis. Je n'appellerais pas ça beaucoup plus pratique, du coup.

(Par exemple si on a une ArrayList très grande et qu'on veut en virer tous les objets marron, mais pas ceux d'autre couleur, manga, je vous raconte pas la complexité. Alors qu'il suffisait de décaler les objets qui restent vers leur nouvel index et de redéfinir la taille.)

Citation:

---

Envoyé par thelvin

Par exemple si on a une ArrayList très grande et qu'on veut en virer tous les objets marron, mais pas ceux d'autre couleur, manga, je vous raconte pas la complexité. Alors qu'il suffisait de décaler les objets qui restent vers leur nouvel index et de redéfinir la taille.

---

Qu'est-ce qui t'en empêche ?
Tu trouves le premier marron, tu trouves combien il y en a, tu shiftes tu repars au nouvel emplacement sans oublier de tenir compte de la taille, tu vires la fin de la liste qui t'interresse plus List.sublist(newSize, list.getSize()).clear(), ensuite tu trim.

Citation:

---

Envoyé par Nemek

Qu'est-ce qui t'en empêche ?
Tu trouves le premier marron, tu trouves combien il y en a, tu shiftes tu repars au nouvel emplacement sans oublier de tenir compte de la taille, tu vires la fin de la liste qui t'interresse plus List.sublist(newSize, list.getSize()).clear(), ensuite tu trim.

---

D'accord, mais cela nécessite de savoir que c'est une ArrayList (ou similaire) et pas une LinkedList (ou similaire.)

Autrement dit, ce n'est pas mon rôle, moi l'utilisateur, d'implémenter ça. L'implémentation de List que j'utilise devrait faire au mieux par elle-même. C'est un problème de principe que je doive utiliser des classes statiques externes pour gérer ça au lieu de juste utiliser les méthodes fournies par l'interface.
(Je sais bien que l'interface ne peut pas définir tout le monde et son neveu, mais je prouve qu'il y a des cas qui s'en retrouvent embarrassés.)

Dans ce cas tu ne créées pas une nouvelle implémentation de List ...

Je plussoie plusieurs propositions faites :
- l'utilisateur n'a pas connaissance de ce qui existe (et en pratique ça peut arriver souvent, le temps de documentation étant souvent limité)
- l'utilisateur préfère réinventer la roue, le fait est que des gens pensent que leur solution est meilleure (et ça peut être du justement au manque de connaissance, ça se recoupe)

Citation:

---

Envoyé par Nemek

Dans ce cas tu ne créées pas une nouvelle implémentation de List ...

---

Moi non. Si nécessaire j'étends ArrayList avec des méthodes adaptées : ce n'est pas optimal dans le détail mais c'est optimal en complexité.

Il y a des exemples plus complexes où cela n'ira pas, par contre.

Citation:

---

Envoyé par thelvin

(Je sais bien que l'interface ne peut pas définir tout le monde et son neveu, mais je prouve qu'il y a des cas qui s'en retrouvent embarrassés.)

---

[hors-sujet] C'est une limitation dû au fait que les interfaces sont figées.
Toutefois cela devrait évoluer avec les "defenders-methods" de Java 8 ;)


@Nemek : chaque implémentation a ses qualités et ses défauts.
Bien sûr la plupart du temps une ArrayList suffit amplement. Mais tu as des cas particulier où elle n'est pas forcément adapté...
Dans ce cas on peut envisager une autre implémentation existante voir carrément d'implémenter la sienne ;)


a++

C'est pas pour faire mon chieur mais bien pour ouvrir mon esprit "étroit" (je précise au cas où) : Quel autre implémentation de la liste autre qu'une chaîne ou un tableau est nécessaire ?

Le seul cas où il m'est arrivé de songer à faire une autre implémentation c'est de mixer le tableau et la chaîne ; comme pour l'implémentation des HashMap. Mais en y réfléchissant, une optimisation des algorithmes d'utilisation de la liste était suffisante.

Citation:

---

Envoyé par thelvin

D'accord, mais cela nécessite de savoir que c'est une ArrayList (ou similaire) et pas une LinkedList (ou similaire.)

Autrement dit, ce n'est pas mon rôle, moi l'utilisateur, d'implémenter ça. L'implémentation de List que j'utilise devrait faire au mieux par elle-même. C'est un problème de principe que je doive utiliser des classes statiques externes pour gérer ça au lieu de juste utiliser les méthodes fournies par l'interface.
(Je sais bien que l'interface ne peut pas définir tout le monde et son neveu, mais je prouve qu'il y a des cas qui s'en retrouvent embarrassés.)

---

Tu crée ta propre classe, qui étends LinkedList et qui, pour supprimer tous les marrons, fait un iterator accompagné de son delete.

Comme je l'ai dit dans la plupart des cas une ArrayList est amplement suffisante...

Mais cela ne répond pas forcément à tous les besoins du monde ;)


a++