Discussion :

[master MI]

Bonjour,
Je dois choisir entre 2 propositions la meilleure,les 2 propositions sont:

Proposition#1:

Code :

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

1
2
3
4
5
interface CapableDeVoler {
     void vole();
}
abstract class Avion implements CapableDeVoler {}
abstract class Oiseau implements CapableDeVoler {}

Proposition#2:

Code :

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

1
2
3
4
5
abstract class Avion {
 
   abstract void vole();
}
abstract class Oiseau extends Avion {}

Laquelle je dois préférer ? la Proposition#1 ou la Proposition#2?
Moi j'ai choisi la Proposition#2

Qu'est ce que vous en pensez?

[thelvin]

J'en pense :

- qu'un oiseau n'est pas un avion et donc qu'il est ridicule d'autoriser Avion truc = new Oiseau(); .
- que programmer par interface donne toujours plus de flexibilité, pour le seul possible coût d'avoir un peu plus de code dans son projet, ce qui est rarement un vrai coût.

[master MI]

oui vous avez raison,un oiseau qui hérite d'un avion simplement parce que
les 2 ont la méthode voler en commun c'est ridicule!!!!
Donc la bonne proposition est la réponse 1.

Merci.

[PhilippeGibault]

Je pense que c'est la proposition 1 qu'il faut préférer.

Déjà parce qu'il faut toujours préférer les interfaces aux classes abstraites. C'est d'ailleurs écrit quelque part dans le Joshua Bloch ( https://www.amazon.fr/Effective-Java.../dp/0134685997 ).

Ensuite, parce qu'une variable doit être définie par son interface et non par sa classe (également dans le Joshua Bloch).

Mais principalement parce que si on change l'implémentation, on ne change pas le code, vu que l'on se réfère à une interface et non une classe.
En fait, dans un programme, on se réfère à un contrat, contrat représenté par une interface.

D'ailleurs, c'est un Design Pattern, le Design Pattern Stratégie ( https://fr.wikipedia.org/wiki/Strat%...de_conception) ).

Ça va aussi avec le D de SOLID (pour Dependency inversion principle https://fr.wikipedia.org/wiki/SOLID_(informatique) ).

Enfin, pour conclure, l'Interface est le contrat. L'interface définit les méthodes. Implémenter une interface, c'est respecter un contrat, avoir une implémentation pour chaque méthodes déclarées.

La classe abstraite, pour moi, ça sert à faire du Template Method (un autre Design pattern https://fr.wikipedia.org/wiki/Patron_de_m%C3%A9thode ).