heritage et parametres variables

bonjour,

j'ai posté dans la section Conception mais il ne semble pas ya avoir grand monde et comme je programme en JAVA peut-etre est-ce plus sa place.

je viens d'implement le pattern strategie pour heriter de la methode calcul() que j'implement avec divers algos.

mon probleme est que cette methode calcul() a un nombre de parametres differents suivant son implementation. Il y a aussi une variation sur le type des parametres (ca c'est moins grave, et encore !! ).

Donc y a t-il un moyen de regler ce probleme ?

je ne comprends pas très bien, mais est ce qu'une simple surcharge ne suffit pas ?

moi non plus je ne comprends pas tout :

Citation:

---

mon probleme est que cette methode calcul() a un nombre de parametres differents suivant son implementation

---

et quel est le problème ?

En fait mon probleme est le suivant,

je possede une classe abstraite

Algo
{
abstract double calcul () ;
}

ensuite je derive pour avoir Algo1 et Algo2

Algo1
{
double calcul (paramType1 param1, paramType2 param2) ;
}

Algo2
{
double calcul (paramType1 param1, paramType2 param2, paramType1 param3) ;
}

le but etant de permettre a d'autre personne d'implementer leur propre Algo en derivant la classe abstraite Algo (s'est le pattern strategie en faite).

le probleme comme vous le voyé est la liste des parametres qui varie suivant le type d'algo et donc la definition de la methode calcul() dans Algo est impossible.

Existe-il un moyen ou un pattern pour resoudre ce probleme et je suis obliger de passer par exemple un vector d'Object de facon a donner un nombre variable de parametres de type inconnu (methode que je prefere eviter) ?

Euh, une Interface ParamType dont hériteraient toutes tes classes ParamTypeX et tu passes une Liste de ParamType à ta méthode calcule...

oui mais comment passer la liste ?
si j'utilise la collection List ou Vector la methode calcul() doit connaitre a l'avance le ce que contient Vector[0],Vector[1], Vector[2], ..., pour etre sur de ne pas se tromper?

Pour chaque classe qui implémente ton interface, tu passes les paramètres dans le constructeur... que tu stockes dans les attributs.
Ainsi dans ta méthode calcul() (sans paramètres), tu peux les utiliser...

De toutes façons, si tous les algos que tu implémentes sont différents, je ne vois pas l'utilité de faire une méthode commune. Sinon, avec Java 1.5, on peut passer à une méthode un nombre quelconque de paramètres. En revanche, il doivent tous être du même type...

Salut,

Citation:

---

Envoyé par Rayndell

Sinon, avec Java 1.5, on peut passer à une méthode un nombre quelconque de paramètres. En revanche, il doivent tous être du même type...

---

Il doivent tous être du même type... dans la déclaration de la méthode.

Mais avec l'abstraction on peut très bien passer n'importe quel type fils, et donc en utilisant un Object on peut passer n'importe quel type ;)


a++

Oui c'est ce que je voulais dire. Désolé.

Autre idée (pseudo-code) :

Code:

---

1 2 3 4 5 6 7 8 9

abstract classs Algo { abstract double calcul(IParametresAlgo parametresAlgo); } interface IParametresAlgo { int getParam1(); int getParam2(); int getParam3(); }

---

De sorte que quand une classe concrète AlgoX a besoin d'un paramètre supplémentaire, tu modifies uniquement IParametresAlgo (et son implémentation) et non plus toute la hiérarchie d'Algo.

Salut,
A mon avis, la meilleure solution c'est celle qui est indiquée par ®om plus haut. C'est-à-dire que chaque sous-classe Algo doit avoir des attributs permettant de le différencier des autres. Ce sont ces attributs qui seront utilisés pour effectuer le calcul dans la méthode héritée. Maintenant, comment tu affectes des valeurs à ces atttributs, c'est à toi de voir, soit en les passant à un constructeur, soit par des setter ... Inutile de se compliquer la vie à vouloir chercher trop loin...

Hello,

Je ne trouve pas cette solution satisfaisante :

Citation:

---

Envoyé par manblaizo

Maintenant, comment tu affectes des valeurs à ces atttributs, c'est à toi de voir, soit en les passant à un constructeur, soit par des setter ... Inutile de se compliquer la vie à vouloir chercher trop loin...

---

Mes raisons :

* passer des arguments au constructeur implique d'instancier une nouvelle stratégie avant chaque calcul ou modification des paramètres de calcul. En fait ça me ferait plus penser à un pattern commande que strategie.

* passer des paramètres avec des setXXX différents pour chaque stratégie concrète nécessite de connaître le type concrèt de la stratégie courante. Par conséquent, on perd le bénéfice du polymorphisme, ça n'est plus non plus un pattern stratégie

Pour terminer, peut être que le pattern stratégie n'est pas adapté à la situation de new.proger...

Citation:

---

Envoyé par MangeurVasqué

Mes raisons :

* passer des arguments au constructeur implique d'instancier une nouvelle stratégie avant chaque calcul ou modification des paramètres de calcul. En fait ça me ferait plus penser à un pattern commande que strategie.

* passer des paramètres avec des setXXX différents pour chaque stratégie concrète nécessite de connaître le type concrèt de la stratégie courante. Par conséquent, on perd le bénéfice du polymorphisme, ça n'est plus non plus un pattern stratégie.

Pour terminer, peut être que le pattern stratégie n'est pas adapté à la situation de new.proger...

---

Alors là, on n'est absolument pas d'accord. D'abord, le pattern Strategy me semble approprié puisqu'il est ici question de changer d'algorithme de calcul en fonction de la situation. Ensuite, on a effectivement besoin de savoir dans quelle situation on se trouve pour pouvoir choisir l'algorithme approprié, et donc instancier la sous-classe Algo appropriée, en lui affectant les attributs nécessaires, avant chaque calcul. Ce qui fait que tes deux arguments tombent à l'eau. Le bénéfice du polymorphisme, il est au niveau de la dépendance d'une autre classe par rapport à l'algorithme réel de calcul. C'est-à-dire qu'une classe "Calculateur", par exemple, n'aurait qu'un attribut de la classe de base Algo, sur lequel elle appelle la méthode calcul(), sans se soucier de l'instance réelle de sous-classe Algo qui lui sera associée à l'exécution. Les implémentations de la méthode calcul() changent selon l'algorithme mais la signature de la méthode reste la même.
Voilà, c'est ce que j'en pense.