Overridable methode call in constructor ?
Résolu
westerndigit
Messages postés
134
Date d'inscription
Statut
Membre
Dernière intervention
-
Char Snipeur Messages postés 9813 Date d'inscription Statut Contributeur Dernière intervention -
Char Snipeur Messages postés 9813 Date d'inscription Statut Contributeur Dernière intervention -
A voir également:
- Java overridable method call in constructor
- 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
3 réponses
Salut.
Je pense qu'un petit morceau de code serait le bien venu pour nous aider à comprendre.
Si je comprend bien, tu appel une méthode surchargeable dans le constructeur d'une classe. Le compilateur t'alerte en te faisant remarqué que dans le cas d'une classe dérivé, il y a un risque qu'une méthode dérivée soit appelée.
Ensuite, il te donne quelques propositions pour résoudre le problème.
Je connais mal java, et en particulier l'instruction "final" (pour moi c'est l'équivalent de const en C++, mais il y a peut être des subtilités).
Si tu rends ta méthode statique, elle sera propre à la classe et non à l'objet (d'ailleurs, je ne vois pas en quoi ça résout le problème) si tu la mets private, elle ne pourra être appelé qu'au sein des méthodes de ta classe (du coup est-ce que ce seront les méthodes du dernier enfant qui seront utilisées ?) ce qui serait étrange pour un "setter".
Je pense qu'un petit morceau de code serait le bien venu pour nous aider à comprendre.
Si je comprend bien, tu appel une méthode surchargeable dans le constructeur d'une classe. Le compilateur t'alerte en te faisant remarqué que dans le cas d'une classe dérivé, il y a un risque qu'une méthode dérivée soit appelée.
Ensuite, il te donne quelques propositions pour résoudre le problème.
Je connais mal java, et en particulier l'instruction "final" (pour moi c'est l'équivalent de const en C++, mais il y a peut être des subtilités).
Si tu rends ta méthode statique, elle sera propre à la classe et non à l'objet (d'ailleurs, je ne vois pas en quoi ça résout le problème) si tu la mets private, elle ne pourra être appelé qu'au sein des méthodes de ta classe (du coup est-ce que ce seront les méthodes du dernier enfant qui seront utilisées ?) ce qui serait étrange pour un "setter".
westerndigit
Messages postés
134
Date d'inscription
Statut
Membre
Dernière intervention
je suis en réunion dès que possible je mets un bout de code
Char Snipeur
Messages postés
9813
Date d'inscription
Statut
Contributeur
Dernière intervention
1 299
Après vérification, final empêche en fait la surcharge d'une méthode. Je pense que c'est la meilleure façon de résoudre le problème (enfin, sans avoir vu le bout de code).
voici le bout de code :
package modelecarnet_1;
import javax.swing.ImageIcon;
/**
*
* @author AnneT
*/
public class Infos extends javax.swing.JPanel {
//prenom, nom, url, numTel, numPort, courriel, rue, ville
/** Creates new form Infos */
public Infos(String [] nl) {
initComponents();
setVisible(true);
setPrenom( nl[0]);
setNom( nl[1]);
setPhoto( nl[2]);
setNumTel( nl[3]);
setNumPort( nl[4]);
setCourriel( nl[5]);
setRue( nl[6]);
setVille( nl[7]);
}
public void setNom(String tmp){
nomLbl.setText(tmp);
}
public void setPrenom(String tmp){
prenomLbl.setText(tmp);
}
public void setPhoto(String tmp){
ImageIcon iconPhoto = new ImageIcon(tmp);
photoLbl.setIcon(iconPhoto);
}
public void setNumTel(String tmp){
numDomicileLbl.setText(tmp);
}
public void setNumPort(String tmp){
numPortableLbl.setText(tmp);
}
public void setCourriel(String tmp){
adresseCourrielLbl.setText(tmp);
}
public void setRue(String tmp){
rueLbl.setText(tmp);
}
public void setVille(String tmp){
villeLbl.setText(tmp);
}
package modelecarnet_1;
import javax.swing.ImageIcon;
/**
*
* @author AnneT
*/
public class Infos extends javax.swing.JPanel {
//prenom, nom, url, numTel, numPort, courriel, rue, ville
/** Creates new form Infos */
public Infos(String [] nl) {
initComponents();
setVisible(true);
setPrenom( nl[0]);
setNom( nl[1]);
setPhoto( nl[2]);
setNumTel( nl[3]);
setNumPort( nl[4]);
setCourriel( nl[5]);
setRue( nl[6]);
setVille( nl[7]);
}
public void setNom(String tmp){
nomLbl.setText(tmp);
}
public void setPrenom(String tmp){
prenomLbl.setText(tmp);
}
public void setPhoto(String tmp){
ImageIcon iconPhoto = new ImageIcon(tmp);
photoLbl.setIcon(iconPhoto);
}
public void setNumTel(String tmp){
numDomicileLbl.setText(tmp);
}
public void setNumPort(String tmp){
numPortableLbl.setText(tmp);
}
public void setCourriel(String tmp){
adresseCourrielLbl.setText(tmp);
}
public void setRue(String tmp){
rueLbl.setText(tmp);
}
public void setVille(String tmp){
villeLbl.setText(tmp);
}
OK, comme ça c'est un peu plus clair.
mettre ta méthode en static ne fonctionnera que si prenomLbl est statique (ce qui m'étonnerai)
private (=non surchargeable, donc un peu similaire à final) fera que tu n'auras plus acces à ta fonction en dehors de la classe.
En fait, la meilleur méthode dépend de ce que tu comptes faire de la classe Infos.
Si tu ne comptes pas la dérivée, met la en final. Si tu compte la dérivée, met toutes tes méthode en final, je ne pense pas que tes setters aient besoin d'être surchargé.
Oui, tu annonce un problème avec setPrenom, mais je pense que tu devrais avoir le même avec toutes les autres méthodes setVille, setRue etc.
mettre ta méthode en static ne fonctionnera que si prenomLbl est statique (ce qui m'étonnerai)
private (=non surchargeable, donc un peu similaire à final) fera que tu n'auras plus acces à ta fonction en dehors de la classe.
En fait, la meilleur méthode dépend de ce que tu comptes faire de la classe Infos.
Si tu ne comptes pas la dérivée, met la en final. Si tu compte la dérivée, met toutes tes méthode en final, je ne pense pas que tes setters aient besoin d'être surchargé.
Oui, tu annonce un problème avec setPrenom, mais je pense que tu devrais avoir le même avec toutes les autres méthodes setVille, setRue etc.