Pièce jointe 267250
interface ou class abstrait ?
Version imprimable
Pièce jointe 267250
interface ou class abstrait ?
Une classe abstraite est là pour définir un comportement commun à toutes les classes qui l'étendront.
L'interface est là pour définir un "contrat", sans se préoccuper de la façon d'implémenter la fonctionnalité.
Il est bien dit que chaque être vivant à sa façon de gérer l'énergie, on n'a donc pas un comportement commun...
Il est dit aussi que tout être vivant consomme de l'énergie, donc, il répond bien à un "contrat" de ce point de vue...
Je ne pense pas trouver une explication aussi simple mais j'aimerais ajouter que dans ta classe abstraite tu peux implémenté un comportement par défaut de la méthode qui sera comportement si la classe fille ne la redéfinit pas. Cependant dans une interface tu n'as besoin que de la signature de la méthode(aucune implémentation n'est nécessaire puisque c'est un contrat) c'est à la classe qui implémente l'interface d’implémenter son comportement. Et si dans ta classe tu as besoin d’implémenter certaines méthodes et d'autres non sache que c'est une classe Abstraite(pense à une classe abstraite Animal et d'autres classes comme chien,chat,.. qui hériteront)
Note : la distinction est déjà devenue un peu plus floue avec le JDK8 qui a ajouté les méthodes par défaut dans les interfaces mais elle le sera encore plus avec le JDK9 qui va introduire les méthodes privées et les méthodes statique privées dans les interfaces (dans le but d’éviter de dupliquer du code dans les méthodes par défaut)
Voir : http://blog.joda.org/2016/09/private...in-java-9.html
Citation:
public static - supported
public abstract - supported
public default - supported
private static - supported
private abstract - compile error
private default - compile error
private - supported
A quand l'héritage multiple ? ;)
C'est en gros la réflexion que je me faisais hier en écrivant cela.
Le truc c'est que la gestion très complexe des états distincts de classes mères distinctes, reste totalement intouchée par ces évolutions des interfaces, qui restent envers et contre tout sans état, donc uniquement des contrats.
Des contrats auxquels on peut maintenant ajouter des comportements qui utilisent le contrat.
C'est déjà un plus à mon sens... ne serait-ce que pour faire de l'héritage multiple de fonctions standards sans état...Citation:
Envoyé par thelvin
Salut,
C'est pas plus mal car les principaux problèmes d'héritage multiple proviennent de conflit entre les états des parents...Citation:
Envoyé par thelvin
Avec de l'héritage multiple de comportement on évite la grande majorité des conflits.
a++
j'ai un gros trou de mémoire: il y a longtemps, longtemps j'avais soutenu (avec exemples à l'appui) qu'on aurait du avoir des blocs statiques dans les interfaces ... un des gars de l'équipe Java m'avait expliqué pourquoi ce n'était pas souhaitable ... mais je ne me souviens pas des arguments dans un sens ou dans l'autre. Une lumière pour me rafraichir les idées? MerciCitation:
Envoyé par bouye
