Code:
1
2
| List<String> maList = new ArrayList<>();
// puis du code pour traiter maList (en passant donc par l'interface) |
Tu peux à tout moment décider de remplacer new ArrayList<>() par new LinkedList<>(). Sans avoir à modifier le reste du code, qui ne passe que par l'interface. Si tu avais typé ArrayList, ce n'est pas que tu aurais nécessairement à modifier le code, mais cela peut être possible, si tu as utilisé des méthodes spécifiques de ArrayList (par exemple trimToSize()).
Mieux encore si :
Code:
1
2
3
4
5
6
| Iterable<String> method() {
// du code qui contruit une liste
ArrayList<String> list = new ArrayList<>();
// ...
return list;
} |
Tu peux à tout moment décider qu'une ArrayList n'est pas le plus judicieux pour implémenter l'ltérateur, et qu'un Set sera plus efficace, ou autre chose (un tableau par exemple), ou autre raison (peu importe en fait). Et tout le code qui appelle ta méthode reste inchangé. Non seulement ça t'évite de modifier tout le code en question, mais si ton code est diffusé sous forme d'API, ceux qui l'utilisent ne seront pas eux non plus obligés de modifier tout leur code si tu as envie de changer l'implémentation à un moment donné.
Lorsqu'on fait ce genre de méthode, il faut toujours se poser la question de quel contrat on veut permettre l'utilisation. Ici, on a décidé que le but était de juste de parcourir une liste d'éléments. Mais si on veut par exemple tout d'un coup permettre de connaitre le nombre d'éléments, on peut remplacer Iterable par Collection, et ce, sans impact sur le code appelant déjà existant (ni même d'ailleurs le code de la méthode en l'occurance). Simplement, ce code existant n'utilisera que la capacité lié au contrat d'Iterable, alors que le nouveau code pourra utiliser celui induit par Collection (qui étend Iterable).
