Discussion :

[Engineer10]

Bonjour , je suis débutant en Java et j'aborde là le chapitre sur les collections .
J'ai beacoup de mal à comprendre le concept de ce chapitre !
Et j'ai une série de questions pour vous !

Quelle est la difference entre ces lignes de codes Svp ?

(1) List m = new ArrayList();

(2) ArrayList m = new ArrayList();

(3)ArrayList <Objets> m = new ArrayList<Objets> () ;

J'ai une seconde question :

A quoi servent les interfaces précisement ? parce que honnetement je ne vois pas la difference avec les classe abstraites ...

Merci d'avance !

[thelvin]

Bonjour,

Quelle est la difference entre ces lignes de codes Svp ?

(1) List m = new ArrayList();

(2) ArrayList m = new ArrayList();

(3)ArrayList <Objets> m = new ArrayList<Objets> () ;

Entre la (1) et la (2), la différence c'est que m est de type List ou ArrayList.
Je te suggère le point de la FAQ sur comment bien utiliser les collections.

Entre la (2) et la (3), la différence est que la (3) utilise les génériques et la (2), non.

La FAQ indique ce que sont les génériques.
En résumé ça permet d'utiliser les collections sans s'embrouiller dans les types d'objets qu'elles contiennent.

En principe l'absence de génériques ne sert à rien et ne devrait plus être possible. Mais les génériques n'existaient pas au début de Java, ça a donc été gardé pour compatibilité avec l'existant.

A quoi servent les interfaces précisement ? parce que honnetement je ne vois pas la difference avec les classe abstraites ...

Effectivement, au départ on pourrait dire que les interfaces ne sont qu'un genre de classes abstraites sans aucun code dedans.
Mais en réalité, la garantie qu'il n'y a aucun code, aucun début d'implémentation dedans, est une garantie forte et utile.
Pour grosso-modo deux raisons :

- C'est un bon outils pour organiser son code proprement. Pour prévoir le futur, on peut vouloir garantir que le type le plus général utilisé, une interface donc, n'impose rien, absolument rien, concernant l'implémentation. Une classe abstraite, on a vite fait d'y mettre des variables et des méthodes concrètes.

- Ça permet le sous-typage multiple. On ne peut hériter que d'une seule classe, concrète ou abstraite. Mais on peut implémenter autant d'interfaces qu'on veut, et aussi hériter de la classe qu'on veut en plus de ça.
Cela vient du fameux problème de l'héritage en losange : si deux classes B et C héritent d'une même classe A, puis qu'à un moment on a besoin d'une classe D qui hérite à la fois de B et C, comment fait-on pour le contrat commun qu'elles ont concernant A ? Aucune solution ne respecte le polymorphisme.
S'il n'y a pas d'implémentation mais juste un contrat, par contre, le sous-typage en losange reste acceptable. Il peut encore poser problème, mais il en résout pas mal, vis-à-vis du polymorphisme.