Imposer du code dans une méthode redéfinie

Bonjour. J'ai une méthode abstraite evalueResultat() dans une classe abstraite AbstractModele.
Lorsqu'on redéfinit la méthode abstraite evalueResultat() dans une classe dérivée de AbstractModele, j'aimerais imposer que cette méthode contienne forcément le code

Code:

---

notifyResultatChanged()

---

à la fin.
Je peux modifier le contenu de la classe AbstractModele car c'est moi l'auteur.
Le but, c'est que quelqu'un qui ne connaît pas le code et qui redéfinit ma méthode soit obligé de mettre

Code:

---

notifyResultatChanged()

---

à la fin.
Est-ce que c'est possible?
Merci.

Tu peux faire ça en deux méthodes dans ta classe abstraite :

Code:

---

1 2 3 4 5 6 7

public final void evalue() { evalueResultat(); notifyResultatChanged(); }   protected abstract evalueResultat();

---

Ca implique que celui qui appelle la méthode ne doit jamais appeler la méthode evalueResultat (il devra passer par la méthode evalue). En revanche ceux qui hériteront de ta classe abstraite n'auront qu'à implémenter la méthode evalue et le code que tu veux "forcer" sera systématiquement exécuté.

Ca doit être le DP "template method" je crois...

Citation:

---

Envoyé par mikael.gibert

Tu peux faire ça en deux méthodes dans ta classe abstraite :

Code:

---

1 2 3 4 5 6 7

public final void evalue() { evalueResultat(); notifyResultatChanged(); }   protected abstract evalueResultat();

---

Ca implique que celui qui appelle la méthode ne doit jamais appeler la méthode evalueResultat (il devra passer par la méthode evalue). En revanche ceux qui hériteront de ta classe abstraite n'auront qu'à implémenter la méthode evalue et le code que tu veux "forcer" sera systématiquement exécuté.

Ca doit être le DP "template method" je crois...

---

Et bien cela dépend si en l'implémentant l'utilisateur fait un super.evalue() ou pas.

Citation:

---

En revanche ceux qui hériteront de ta classe abstraite n'auront qu'à implémenter la méthode evalueResultats et le code que tu veux "forcer" sera systématiquement exécuté.

---

Citation:

---

Envoyé par deathness

Et bien cela dépend si en l'implémentant l'utilisateur fait un super.evalue() ou pas.

---

Comme l'a dit mikael.gibert, et pointé BenWillard, c'est la méthode evalueResultats() qui sera implémentée et pas la méthode evalue() qui est marquée final pour justement interdire sa réécriture ;).

Citation:

---

Envoyé par le y@m's

Comme l'a dit mikael.gibert, et pointé BenWillard, c'est la méthode evalueResultats() qui sera implémentée et pas la méthode evalue() qui est marquée final pour justement interdire sa réécriture ;).

---

Oui j'avais lu trop vite et loupé le final! :cry:

Donc il faut avertir le programmeur qui dérive la classe AbstractModele qu'il doit, pour l'évaluation, utiliser la méthode evalue() et pas la méthode evalueResultat()?
Donc le problème est le même que de le prévenir qu'il doit ajouter notifyResultatChanged() à la fin de la méthode evalueResultat() ?
Je ne vois donc pas le gain qu'on a à utiliser la méthode final evalue puisque de toute façon il faut prévenir le programmeur.
J'ai rien compris ou ce que je dis est juste?

Oups, petite faute d'inattention, merci d'avoir corrigé!

Donc, tout dépend : qui appelle la méthode evalue ? Elle est publique pour pouvoir être accédée depuis n'importe où, tandis que la méthode à surcharger (abstraite donc) est protected, ce qui signifie qu'elle n'est visible que par héritage et par les classes du même package.

Si les appelants de ta méthode sont les classes héritées, aux développeurs de lire la documentation, ce qui revient au même...

En revanche le cas que j'imaginais c'était que les appelants étaient externes (cad non hérités ni même package). Dans ce cas ils ont quelque chose du genre :

Code:

---

1 2 3

AbstractModele model = une instance concrète model.evalue();

---

Tout dépend de ton cas en d'autres termes ;) Je pensais que les personnes développant les appelants n'étaient pas les même que celles développant les dérivées.

Merci pour vos réponses.
En fait, la classe abstraite doit être héritée dans le même package (le but est de faire un code facile à faire évoluer par un autre programmeur).
Sinon, pour éviter les erreurs, je peux peut-être donner des noms plus explicites:
Je garde le nom evalue() et je remplace le nom evalueResultat() par methodeEvaluation(), comme ça le programmeur ne peut pas se tromper lorsqu'il veut évaluer le résultat. ;)

Le nom comme la description des méthodes et de la classe sont tout aussi important ;)

Tu peux d'ailler donner dans la description de la classe des exemple d'utilisation de celle-ci!

Pour pousser le vice, tu peux passer par une interface : Ton interface contient uniquement la signature de la méthode qui doit être appelée, ta classe abstraite implémente cette méthode (marquée final pour ne pas être héritée) en déléguant l'évaluation à la méthode abstraite evalueResultat puis appelle la méthode notifiyResultatChanged.

Un petit exemple est plus parlant qu'un long discours :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

public interface Model { void evalue(); }   public abstract class AbstractModel implements Model { @Override public final void evalue() { evalueResultat(); notifyResultatChanged(); }   protected abstract void evalueResultat();   private void notifyResultatChanged() { //... } }

---

Ainsi les appelants de ta classe n'auront qu'à passer par l'interface qui définit le contrat et cela devrait éviter les confusions.

Citation:

---

Envoyé par mikael.gibert

Pour pousser le vice, tu peux passer par une interface.

---

Je dirais même que ce n'est pas pousser le vice mais juste la bonne façon de faire ^^.

Je n'ai pas compris l'intérêt d'ajouter le

Code:

---

implements model

---

pour un programmeur qui doit dériver la classe abstraite AbstractModel.
C'est moi qui écris cette classe abstraite (qui n'aura plus à être modifiée), donc je sais que je dois implémenter la méthode evalue().
Donc quelle est l'utilité du

Code:

---

implements model

---

?

Disons que c'est plus flexible quand le type le plus haut est une interface.

Plusieurs raisons :
- Il est possible de définir, donc d'imposer, du code d'exécution dans une classe, même abstraite. Une interface, par contre, n'impose que l'implémentation des méthodes qu'elle déclare.
Ainsi, si un jour AbstractModel fait des choses qui ne conviennent pas pour tout, il sera toujours possible de faire d'autres classes qui implémentent Model. Ça arrive souvent quand on fait des gros chantiers sur le code.

- Il est possible d'étendre ou d'implémenter autant d'interfaces qu'on veut. Mais on ne peut étendre qu'une seule classe.
Si jamais un Model avait un jour besoin d'être aussi d'autres choses (genre un RestApiAnswer ou je sais pas,) ce ne serait pas possible en lui imposant d'hériter d'une classe. Mais c'est sans problème en lui imposant d'implémenter une interface.