Quote:
j'espère que j'ai été claire dans l'explication
Non... ;)
Mais on va essayer de t'aider quand même :)
Quote:
D'après la documentation que j'ai consulté quand on utilise une classe abstract pour toutes les méthodes abstract de cette classe doivent être redédéfinit dans les sous-classes de la classes abstract.
Oui.
Quote:
Et donc cela signifie que dans cette exemple qu'il faut absolument que je redéfinisse la méthode calculer() à la fois dans la classe CosMoinsNomme et dans la classe ImprimerFonction.
Non
Ou du moins pas forcément. Si tu as
class ImprimerFonction extends FonctionNommee
C'est oui
Mais si tu as
class ImprimerFonction extends CosMoinsNommee
C'est non car dans ce cas ImprimerFonction hérite de l'implémentation de calculer dans CosMoinsNommeee Et tel que tu poses ton problème c'est cee que tu veux.
Donc pour résoudre pas besoin d'annotions ou autres trucs fumeux. Simplement tu dérives de CoisMoinsNomme au lieu FonctionNommee
Maintenant si tu me le permets, le simple fait de dériver pour écrire ImprimerFonction me semble une faute de programmation. Enfin pas une faute stricto sensu, mais un viol des bons principes des Design Pattern. Bon si c'est ce qu'on t'a demandé de faire, on va pas discuter.
Sinon ImprimerFonction ne devrait pas dériver de quoi que ce soit, mais être une classe qui implémente une fonctionnalité d'impression, et alors CosMoinsNommee doit avoir comme membre une instance de ImprimerFonction et la méthode imprimer de CosMoinsNommee invoquera alors les méthodes de ImprimerFonction.
Gros avantage, ImprimerFonction va servir tout le temps, c'est ce que appelle un découplage. Sinon, le jour où tu écris une classe CosPlusNommee tu vas devoir encore dériver pour pourvoir l'imprimer.
J'espère que j'ai été cair dans l'explication. N'hésite pas à me demander des précisions ;) :)
Non... ;)
Mais on va essayer de t'aider quand même :)
Oui.
Non
Ou du moins pas forcément. Si tu as
class ImprimerFonction extends FonctionNommeeC'est oui
Mais si tu as
class ImprimerFonction extends CosMoinsNommeeC'est non car dans ce cas ImprimerFonction hérite de l'implémentation de calculer dans CosMoinsNommeee Et tel que tu poses ton problème c'est cee que tu veux.
Donc pour résoudre pas besoin d'annotions ou autres trucs fumeux. Simplement tu dérives de CoisMoinsNomme au lieu FonctionNommee
Maintenant si tu me le permets, le simple fait de dériver pour écrire ImprimerFonction me semble une faute de programmation. Enfin pas une faute stricto sensu, mais un viol des bons principes des Design Pattern. Bon si c'est ce qu'on t'a demandé de faire, on va pas discuter.
Sinon ImprimerFonction ne devrait pas dériver de quoi que ce soit, mais être une classe qui implémente une fonctionnalité d'impression, et alors CosMoinsNommee doit avoir comme membre une instance de ImprimerFonction et la méthode imprimer de CosMoinsNommee invoquera alors les méthodes de ImprimerFonction.
Gros avantage, ImprimerFonction va servir tout le temps, c'est ce que appelle un découplage. Sinon, le jour où tu écris une classe CosPlusNommee tu vas devoir encore dériver pour pourvoir l'imprimer.
J'espère que j'ai été cair dans l'explication. N'hésite pas à me demander des précisions ;) :)