Discussion :

[weabow]

Bonjour,

J'ai fureté sur le web pour différencier avantages/inconvénients des 2 approches.

En résumé, voici la question que je me pose :

Que peut faire une Classe abstraite que ne peut pas faire une Interface ?
(Mis à part d'avoir du code, bien sûr)

L'Interface me semble plus riche en possibilités (capacité à implémenter plusieurs Interfaces dans une classe). Donc, pourquoi ne pas s'orienter plus ou moins systématiquement sur des Interfaces ?

Christian

[clubist]

on peut dire que l'Interface est une classe 100 % abstraite.

Bon, on peut travailler avec les deux approches dans le même projet car ils sont pas des approches concurrents, chacune répond à des besoins bien précis.

Si on doit modéliser un type d'objet qui est encore abstrait et qui peut avoir des types plus concrets on utilise la notion de la classe abstraite

Exemple : on doit modéliser un parc d'animaux ( éléphant, chien, lion, tigre, oiseau,...). dans ce cas on sait bien que l'ensemble de ces animaux mange, boit déplace et crie mais de qu'elle manière ? c'est un peu ambigu, alors on doit définir une classe abstraite Animal dans lequel on déclare ces 4 comportements ( méthodes) et on doit les implémenter dans chaque sous-type ( chien hérite de l’animal, etc...).

Pourquoi de interfaces ?

Maintenant si on doit modéliser des comportement bien précis qui caractérisent des types d'animaux et non d'autres, exemple
le chien :
1-faire le beau

2-faire des câlins

3-faire une « léchouille »

Je ne vois pas le problème… Tu n'as qu'à ajouter ces méthodes dans la classe Animal !

Ouh là ! Vous vous rendez compte que vous obtiendrez des lions qui auront la possibilité de faire le beau ? Dans ce cas, on n'a qu'à mettre ces méthodes dans la classe Chien, mais j'y vois ce problème :
si vous faites cela, on perd le polymorphisme ! Vous ne pourrez pas appeler vos objets par le biais d'un supertype. Pour pouvoir accéder à ces méthodes, vous devrez obligatoirement passer par une référence à un objet Chien. Pas terrible, tout ça !

Alors si un jour tu modélisera un chenil tu dois implémenter de nouveau ces 3 derniers comportements alors qu'ils sont les mêmes.

et pour cela on doit utiliser une interface qui sera implémenté par les classes qu'ils auront besoin et on n'oublie pas que l'héritage multiple n'est pas permis en java alors qu'on peut implémenter plusieurs interfaces.

[weabow]

C'est plus clair : merci.

C'était l'accès par le biais des super-types qui me manquait.

Très bon weekend

Christian

[thelvin]

Je vais résumer un peu :

"mis à part avoir du code" ? Mais c'est une différence super importante !

Autres différences :
- Peut avoir des variables d'instance et non-final (une interface ne peut avoir que des variables public static final.)
- Peut avoir des membres (méthodes et variables) private et protected. (Dans une interface tout est public.)

"Donc, pourquoi ne pas s'orienter plus ou moins systématiquement sur des Interfaces ?"
=> Pour tous les cas où elles suffisent pas.
Souvent tu auras des classes qui implémentent la même interface, et beaucoup de code commun. Une interface ne peut pas contenir de code et donc pas fournir ce code commun*. Une classe abstraite le peut.

* Depuis Java 8 c'est un peu plus compliqué que ça : une interface peut contenir du code et définir certains codes communs à tous ses implémenteurs. Mais une interface ne peut pas avoir de variable d'instance, et ne peut donc pas définir de code qui utilise des variables d'instance. Elle ne peut qu'appeler les méthodes qu'elle définit.

[weabow]

Merci pour ces précisions.

Christian