Discussion :

[bomehc]

Bonjour,

Voilà le problème :

J'ai une classe A qui étend File. J'aimerais la doter d'un constructeur A(File f) (constructeur qui ne fait, d'ailleurs, pas grand chose de plus que convertir l'objet f de classe File en classe A).

Cependant, je me fais jeter par l'IDE parce que le constructeur File() n'existe pas.

Bon, je comprends bien son problème, mais comment puis-je faire pour lui demander d'utiliser f comme base de mon nouvel objet?

Bon, évidemment, super(f.toString()) marcherait, mais bon... Il doit bien y avoir quelque chose de plus élégant quand même, non?

Même si cette solution fonctionne dans ce cas précis, je suis sûr que je re rencontrerai le problème dans des cas moins simples

Merci de m'aider

[tchize_]

vous ne pouvez pas prendre une instance d'une classe (ici f) et la "transformer" en la classe courante. En l'occurence ici, le mieux est d'appeler un constructeur de File() qui prenne en paramètre des données que vous récupérer de f.

Quel est l'intérêt de sous-classer File au passage?

[bomehc]

Bonjour,

Merci pour la réponse.

J'ai étendu File pour lui ajouter une méthode qui renvoie les noms des fichiers contenu dans le dossier (si f est un dossier) et ayant une extension spécifique. En gros, un list() amélioré.

J'aurais pas dû faire comme ça?

D'ailleurs, tant qu'on en est à de l'esthétisme, je pensais ajouter à cette classe une procédure de chargement et d'enregistrement du fichier selon son extension. Est-ce que je devrais la mettre dans cette classe, ou plutôt créer une nouvelle classe contenant un File comme attribut?

[adiGuba]

Cependant, je me fais jeter par l'IDE parce que le constructeur File() n'existe pas.

Sans message d'erreur exact ni le code exact ce n'est pas forcément évident de comprendre pourquoi "tu te fais jeter"...

Bon, évidemment, super(f.toString()) marcherait, mais bon... Il doit bien y avoir quelque chose de plus élégant quand même, non?

C'est l'appel au constructeur parent qui pose problème ?

J'ai étendu File pour lui ajouter une méthode qui renvoie les noms des fichiers contenu dans le dossier (si f est un dossier) et ayant une extension spécifique. En gros, un list() amélioré.

Heu... Pourquoi ne pas utiliser directement list(FilenameFilter) ?

a++

[bomehc]

Sans message d'erreur exact ni le code exact ce n'est pas forcément évident de comprendre pourquoi "tu te fais jeter"...

Le message d'erreur c'est "impossible de trouver le constructeur File() dans java.io.File"

C'est l'appel au constructeur parent qui pose problème ?

D'après le message précédent, il semblerait. File n'a pas de constructeur ayant un File comme paramètre, du coup l'IDE tente de se rabattre vers le constructeur par défaut File(), mais comme il n'existe pas non plus, je l'ai dans l'os.

Heu... Pourquoi ne pas utiliser directement list(FilenameFilter) ?

Je pense que le fait que je ne connaisse pas cette classe a dû jouer à un moment ou un autre. Très probablement ^^. Je vais utiliser ça du coup, ça me parait mieux.

Merci pour tes réponses

[tchize_]

L
D'après le message précédent, il semblerait. File n'a pas de constructeur ayant un File comme paramètre, du coup l'IDE tente de se rabattre vers le constructeur par défaut File(), mais comme il n'existe pas non plus, je l'ai dans l'os.

L'IDE n'a rien à voir dans l'histoire. Et java n'essaie jamais d'utiliser le constructeur parent prenant un File. Quand vous n'appelez pas un constructeur explicite du parent, en java, utilise toujours le constructeur par défaut du parent, qui est celui ne prenant pas de paramètre. Comme File n'a pas de constructeur par défaut, toute classer héritant de File devra avoir un constructeur explicite déléguant explicitement à un des constructeurs de File

[bomehc]

Oui oui, pardon si je me suis mal exprimé, je ne reprochais rien à l'IDE en particulier, j'ai bien compris que le problème était simplement souligné par l'IDE.

Bon, du coup, va pour un super(f.toString());

Merci