[JAVA] paramètres du constructeur
Résolu
plopiplopou
-
varfendell Messages postés 3259 Date d'inscription Statut Membre Dernière intervention -
varfendell Messages postés 3259 Date d'inscription Statut Membre Dernière intervention -
A voir également:
- Constructeur java
- Waptrick java football - Télécharger - Jeux vidéo
- Jeux java itel - Télécharger - Jeux vidéo
- Eclipse java - Télécharger - Langages
- Java apk - Télécharger - Langages
- Waptrick java voiture - Télécharger - Jeux vidéo
7 réponses
Salut,
Décompose tout ces paramètre en une ou plusieurs classe...
Ton constructeur n'aura alors plus qu'a appeler ces classe pour initialiser les paramètres
As tu vraiment besoin de 42 paramètres? A quoi cela correspond il?
Décompose tout ces paramètre en une ou plusieurs classe...
Ton constructeur n'aura alors plus qu'a appeler ces classe pour initialiser les paramètres
As tu vraiment besoin de 42 paramètres? A quoi cela correspond il?
Salut,
Je préférerais passer un seul paramètre: un JavaBean maison (faire des setXX() avant de le passer et des getXX() lors de l'utilisation)...
43 paramètres c'est tout simplement trop difficile à lire autrement.
++
Je préférerais passer un seul paramètre: un JavaBean maison (faire des setXX() avant de le passer et des getXX() lors de l'utilisation)...
43 paramètres c'est tout simplement trop difficile à lire autrement.
++
je comprends au niveau de l'accessibilité et de la mutatibilité c'est plus lisible, c'est exactement ce que j'ai fait pour l'interaction avec l'objet en lui même (même si en tout sur les setters and getters y en a 84 xD), mais avant de pouvoir utiliser ces méthodes il me faut déjà construire l'objet et c'est là que ca se complique.
de plus utiliser cette procédure revient a faire appel a autant de méthodes.
de plus utiliser cette procédure revient a faire appel a autant de méthodes.
ils représentent le résultat d'une 40aines d'autres fonctions de calculs stochastiques, financier ou mathématiques permettant de définir un statut global sur un produit financier.
Quand tu dis en plusieurs classes, je devrais les décomposer dans quels sens?
Quand tu dis en plusieurs classes, je devrais les décomposer dans quels sens?
décomposer c'est faire des groupes de tes 42 attributs...par exemple dans une voiture tu as des pièces pour les pneu, pour le moteur, pour la carrosserie, et pour l'électronique.
Et bien au lieu de faire ta classe voiture avec toute les pièces d'un coup (donc énormément de paramètre), tu décompose tes paramètres en plusieurs classes...plus compréhensible, et donc le constructeur de ta classe voiture fera ici appel ici au quatre constructeur (pneu/moteur/carrosserie/électronique) ,ce qui rend plus simple l'utilisation future des composant et moins compliqué le codage.
Donc regroupe tes attributs par type, crée un objet (par exemple l'objet moteur qui sera définit par le nombre de cylindre, le nombre de chevaux et le volume du réservoir). Ça regroupe ici 3 attribut dans un seul.
Et bien au lieu de faire ta classe voiture avec toute les pièces d'un coup (donc énormément de paramètre), tu décompose tes paramètres en plusieurs classes...plus compréhensible, et donc le constructeur de ta classe voiture fera ici appel ici au quatre constructeur (pneu/moteur/carrosserie/électronique) ,ce qui rend plus simple l'utilisation future des composant et moins compliqué le codage.
Donc regroupe tes attributs par type, crée un objet (par exemple l'objet moteur qui sera définit par le nombre de cylindre, le nombre de chevaux et le volume du réservoir). Ça regroupe ici 3 attribut dans un seul.
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
mais avant de pouvoir utiliser ces méthodes il me faut déjà construire l'objet et c'est là que ca se complique.
de plus utiliser cette procédure revient a faire appel a autant de méthodes.
==> pourquoi c'est tellement compliqué de construire un tel objet ? Je ne comprends pas.
Si tu as des problèmes de performance, il est vrai que ce que j'ai proposé est moins rapide qu'un appel avec 43 paramètres. Mais il y a des chances minimes que l'utilisateur s'en rende compte, la surcharge d'un constructeur et de 86 appels de méthodes est négligeable.
de plus utiliser cette procédure revient a faire appel a autant de méthodes.
==> pourquoi c'est tellement compliqué de construire un tel objet ? Je ne comprends pas.
Si tu as des problèmes de performance, il est vrai que ce que j'ai proposé est moins rapide qu'un appel avec 43 paramètres. Mais il y a des chances minimes que l'utilisateur s'en rende compte, la surcharge d'un constructeur et de 86 appels de méthodes est négligeable.
Ok, bha je vais adopter ce type de décomposition et donc créer 3 classes au lieu d'une pour passer les paramètres en fonction de leur type de calcul et une classe qui prendra ses 3 sous classes...
Maintenant ca risque aussi d'enlever de la lisibilité sur le code.
Maintenant ca risque aussi d'enlever de la lisibilité sur le code.
au contraire, decomposer le code le rend plus lisible. Tu n'est pas obliger de faire que trois "sous classe", tu peut en faire 5 ou 10...
De plus n'hésite pas a creer de nouveau type:
le type se comporte un peut comme une classe: c'est toi qui definit de quoi il est composé, du nombre d'element qu'il contient, ainsi ai lieu de passer 46 parametres, tu peut passer 4 ou 5 types.
De plus n'hésite pas a creer de nouveau type:
le type se comporte un peut comme une classe: c'est toi qui definit de quoi il est composé, du nombre d'element qu'il contient, ainsi ai lieu de passer 46 parametres, tu peut passer 4 ou 5 types.
==> pourquoi c'est tellement compliqué de construire un tel objet ? Je ne comprends pas.
Il n'y a rien de compliqué, ma requête exprime avant tout un problème de lisibilité !
Si tu as des problèmes de performance, il est vrai que ce que j'ai proposé est moins rapide qu'un appel avec 43 paramètres. Mais il y a des chances minimes que l'utilisateur s'en rende compte, la surcharge d'un constructeur et de 86 appels de méthodes est négligeable.
En fait l'utilisateur du résultat étant un ordinateur et par soucis d'intéragir rapidement avec des prix en temps réels il m'est important de gérer ce soucis de timing
Il n'y a rien de compliqué, ma requête exprime avant tout un problème de lisibilité !
Si tu as des problèmes de performance, il est vrai que ce que j'ai proposé est moins rapide qu'un appel avec 43 paramètres. Mais il y a des chances minimes que l'utilisateur s'en rende compte, la surcharge d'un constructeur et de 86 appels de méthodes est négligeable.
En fait l'utilisateur du résultat étant un ordinateur et par soucis d'intéragir rapidement avec des prix en temps réels il m'est important de gérer ce soucis de timing