Génerics et Héritage, comment concilier?

Bon j'explique mon problème :
J'ai fait une classe AbstractFunction, abstraite, qui va me permettre de modéliser des fonctions quelconques, en y déclarant quelques méthodes comme eval() (calcule l'image en un pt), derive(), integre, ... et y définit des méthodes comme le thm des valeurs intermédiares, thm de Newton, du point fixe, ...

Jusque-là, tout va bien, une belle classe générale.

Ensuite je crée une classe Polynome, qui hérite de AbstractFunction, tout va bien, mes coefficients sont réels...
Seulement voilà, je veux être général par souci de réutilité j'implémente cette classe avec des types génériquesn afin de pouvoir créer des polynômes de matrice par exemple, de la manière suivante : Polynome p = new Polynome<Matrix>( ... );

Je ne dois globalement pas redéfinir les méthodes qui font + - * /, ni même derive(), integre() de la classe abstraite, tout ça va bien...
Mais le problème monstrueux est le suivant : comment appliquer le théorême des valeurs intemédiares à un polynôme de matrices? Il n'y a en effet pas d'ordre sur Rn x Rm... A la limite on se dit c'est facile, onj utilise une norme usuelle sur les matrices (je vous épargne la définition) et ça va fonctionner... Et bien non car une norme est >= 0 et je ne peux pas aller dans le négatif, ennuyeux pour le thm...

Enfin voilà j'espère que je me suis fait comprendre et qu'il y aura qqn pour m'aider, je ne suis peut-être pas au bon endreoit, j'aurais peut-être dû poster du côté algorithmique...

Merci d'avance pour vos réponses

J'avoue ne pas y avoir compris grand chose (il est trop tot :lol:) mais de deux choses :
* soit ton problème est resolvable mathematiquement mais la ce n'est pas moi qui vais t'aider :oops: mais plutot le forum algo, mais le solution peut etre d'utiliser une fonction tierce dans ton algo pour gerer ton cas particulier....

* soit il s'agit d'un problème de conception et je peut peut etre essayer.

Je dirais que tu essaye de trop "factoriser" ton code, serait ce pas possible de redefinir la focntion qui te pose problème? Autrement dit, au lieu de passer par une classe abstraite, passe initialement par une interface, et utilise une classe abstraire apres seulement pour regrouper les classes ayant un meme comportement, les autres pouvant directement implémenter l'interface....

Salut,

rien ne t'empeche de surcharger dans ta classe fille, le polymorphisme se chargera d'aller chercher la bonne fonction...
non ?

mavina

Oui, surcharger, ok, mais comment pour appliquer le fameux Théorême? Il n'y a pas d'ordre sur les matrices...

A part faire un truc du style

Code:

---

1 2 3

if(T instanceof Matrix) throw new IllegalPolynomeException("Non comparable Polynome");

---

mais faut avouer que c'est pas très beau...

Tu ne devrais pas avoir une seule classe AbstractFunction... Mais plutôt, par exemple une classe AbstractFunction qui définit les opérations communes à tous les types (add, substract...).
Ensuite 2 classes abstraites héritant de AbstractFunction (AbstractRealFunction, AbstractMatrixFunction) qui définissent les opérations particulières... Et après tes classes concrètes...

Si j'ai bien compris, tu ne peux appliquer le théorème que pour des fonctions qui s'appliquent sur un ensemble ordonné.

Tu peux essayer d'implémenter ton théorème dans une nouvelle classe :

Code:

---

1 2 3 4 5 6 7 8

class TheoremeValeursIntermediaires<T extends AbstractFunction<D>, D extends Comparable> { public D calculerTheoremeValeursIntermediaires(T fonction, D a, D b, D imageC) { .. } }

---

Je n'ai vraiment pas compris le contexte, mais rien que le titre me pousse à te proposer :

Code:

---

public class Polynome<? extends Matrix> extends AbstractFunction

---

Ce qui te permettra de déclarer :

Code:

---

1 2	public class Matrix22 extends Matrix {...} Polynôme<Matrix22> p = new Polynôme<Matrix22>

---

Ca peut peut-être t'arranger pour tes calculs ?

Ben pour être hnnête ça m'arrange pas vraiment tout ça :
Quelque soit le paramètre que je mets dans mes polynômes (double, Matrix, ... ), ce polynôme est toujours hérité de AbstractFunction, qui elle-même déclare la méthode conctrète du thm des valeurs intermédiares, je voudrais savoir comment ne fusse qu'empêcher cette m'éthode d'être invoquée sur un Polynome<Matrix>, et déclarer cette incompatibilité dans la classe Polynôme même, sans redéfinir la méthode du thm des valaurs intermédiares.

Par ailleurs j'ai une autre question : pour les générics avec mes polynômes, ne fusse que pour ajouter deux polynômes ça va, on ajoutte les coefficients un-à-uns (à quelques détails techniques près), on utilise donc tout simplement l'opérateur + pour les types primitifs, facile...
Mais dans le cas où le polynôme est paramétré par des matrices, l'implémentation elle-même de la méthode add pour les polynômes ne change pas, on ne fais toujours qu'ajouter les coefficients un à un, mais il n'est plus question cette fois d'utiliser l'opérateur +, mais la méthode add déclarée dans Matrix... Comment résoudre ce problème de conflit? Je ne vais quand même pas déclarer 2 fois la même méthode, une fois pour les primitifs, et uen fois pour les objets étendus de MathObject (une super classe abstraite avec notement la déclaration de la méthode add et des trucs basiques su style que partagent les objets mathéatiques comme les polynomes, les matrices, les nombre complexes, ...)

Enfin voilà je sais pas si j'ai té plus clair que dans mes posts précédents, merci en tout cas pour votre aide ;-)

A mon avis ... tu t'es embarqué dans une sacrée galère ... et j'espère que tu as les nerf solides (et de bonnes connaissances de prog objet et UML).

Perso, je pense que la solution à ton problème est le Design Pattern "Visitor".

Je te laisse te renseigner dessus (cf site du "Gang of Four"), et me dire ce que tu en pense. Tu verra .. il vaut mieux prendre son temps pour le comprendre en entier. Mais je pense qu'il apporte une solution à ton problème.

l'étape suivante serait de regrouper le genre de données que tu utilise dans une logique d'héritage (les matrices d'un côté, les entiers / décimaux / .... / réels / complexes de l'autre (chacun héritant du précédent)) ...

Mais comme je le disais au départ, tu t'attaque à gros.

PS : "Le Design Pattern Visitor permet de virer les 'instance of' d'un programme" dixit mon boss (et je viens de comprendre pourquoi ;) merci)

petit coup de pouce quand même (j'ai quelques scrupules à te laisser trop dans le vague) :

L'objet visité serait ton objet héritant de AbstractFunction et le visiteur serait le type de données.

Citation:

---

Envoyé par Razgriz

Je ne vais quand même pas déclarer 2 fois la même méthode, une fois pour les primitifs, et uen fois pour les objets étendus de MathObject (une super classe abstraite avec notement la déclaration de la méthode add et des trucs basiques su style que partagent les objets mathéatiques comme les polynomes, les matrices, les nombre complexes, ...)

---

Alors la, tout à fait si !! Les nombres sont des MathObjects, non ? Donc tu ne dois pas utiliser de types primitifs, mais des classes qui implémentent MathObject et qui représentent un nombre.

Tu peux écrire une interface que n'implémentent que les classes sur lesquelles tu peux appeler cette fonction. On l'appelle Numeric :

Code:

---

public Resultat<E extends Numeric> computeIntermediaryValues(Polynome<E extends Numeric> p);

---

Tu devrais regarder et t'inspirer du Collections Framework (package java.util). Les interfaces, les classes, et les utilitaires (classe Collections).

Genre :
- Interface générale (equivalent de Collection) : MathObject qui définit addition, comparaison, etc...
- Des sous interfaces (equivalent de Set, List) : Numeric, Matrix, Polynome <E extends MathObject> définissent les méthodes supplémentaires que peuvent avoir des polynômes, des matrices ou des nombres simples (distances, etc..)
- Des implémentations (réel utilisant un BigDecimal, entier utilisant un BigInteger, ...).
- Des utilitaires (equivalent de Collections) : Classes offrant des méthodes statiques utiles.

pour les déclarations des deux méthodes, si j'utilise les wrapper des types primitifs ça va marcher? Puet-être y a-t-il une solution à regarder de ce côté là...

Comme tu ne peux pas hériter des types primitifs (ils sont finaux) ni surcharger les opérateurs comme en C++, tu devras plus probablement passer par une classe qui contient sa valeur comme attribut.

Tu peux aussi hériter des classes BigDecimal et BigInteger, qui représentent des nombres, mais sans limite de taille ou de précision (ce qui est quand même mieux pour faire des maths).