Quote:
En fait je viens de m'aperçevoir que j'ai fait une erreur dans la lecture du sujet.
Hum, je crois que tu es encore dans l'erreur...
Quote:
class ImprimerFonction extends FonctionNommee, mais le sujet ne le précise pas explicitement
Voilà qui me rassure quant à la valeur du sujet :)
Quote:
Donc tu as raison, je vais déclaré ImprimerFonction en sous-classe de CosMoinsNommee, comme ça le problème sera reglé.
Non :!:
Si tu fais une sous classe *ton* problème tel que tu as dit l'avoir rencontré dans ton premier message sera réglé. Mais si tu lis bien ton énoncé, je ne pense pas que c'est ce qu'il faut faire.
Quote:
La classe comportera donc un champ FonctionNommee qui est la fonction à étudier
Je t'avais parlé, pour une bonne conception, d'une classe "Fonction" qui détenait un membre ImprimerFonction pour imprimer des résultats.
Je crois que l'énoncé te demande la même chose, mais dans l'autre sens ce qui est correct aussi. C'est à dire une classe ImprimerFonction (qui dérive de rien de particulier donc) et qui a un membre "FonctionAImprimer" de type FonctionNommee et qui pourrait être par exemple CosMoinsNommee. Et ImprimeFonction appelle la fonction calcule de la classe qui dérive de FonctionNommee (par exemple CosMoinsNommee) pour imprimer.
En terme de programmation cette façon de faire s'appelle le Desing Pattern Strategy.
Un peu de (pseudo) code pour te fixer les idée:
class CosMoinsNommee extends FonctionNomme
{
public double calculer(double x) { /* je calcule y en fonction de x *:}
}
class ImprimeFonction
{
private FonctionNommee fn = new CosMoinsNomme(); // car tout ce qui dérive de FonctionNommee est du type de la class abstraite :)
private double bornesup, borneinf // à initialiser
public void lister() {/* j'imprime/liste ce qu'il faut en fonction de borneinf et bornesur et du résultat de fn.calculer(); */}
}
C'est tout simple :) Kapito ?
Hum, je crois que tu es encore dans l'erreur...
Voilà qui me rassure quant à la valeur du sujet :)
Non :!:
Si tu fais une sous classe *ton* problème tel que tu as dit l'avoir rencontré dans ton premier message sera réglé. Mais si tu lis bien ton énoncé, je ne pense pas que c'est ce qu'il faut faire.
Je t'avais parlé, pour une bonne conception, d'une classe "Fonction" qui détenait un membre ImprimerFonction pour imprimer des résultats.
Je crois que l'énoncé te demande la même chose, mais dans l'autre sens ce qui est correct aussi. C'est à dire une classe ImprimerFonction (qui dérive de rien de particulier donc) et qui a un membre "FonctionAImprimer" de type FonctionNommee et qui pourrait être par exemple CosMoinsNommee. Et ImprimeFonction appelle la fonction calcule de la classe qui dérive de FonctionNommee (par exemple CosMoinsNommee) pour imprimer.
En terme de programmation cette façon de faire s'appelle le Desing Pattern Strategy.
Un peu de (pseudo) code pour te fixer les idée:
class CosMoinsNommee extends FonctionNomme { public double calculer(double x) { /* je calcule y en fonction de x *:} } class ImprimeFonction { private FonctionNommee fn = new CosMoinsNomme(); // car tout ce qui dérive de FonctionNommee est du type de la class abstraite :) private double bornesup, borneinf // à initialiser public void lister() {/* j'imprime/liste ce qu'il faut en fonction de borneinf et bornesur et du résultat de fn.calculer(); */} }C'est tout simple :) Kapito ?