Discussion :

[Ecosmose]

Bin voila je suis nostalgiques de Eclipse lorsque je n'arrive pas à trouver la fonction creat getters and setters du ménu contexte déroulant (clic droit)

j'ai essayé de faire 'extract method..' lorsque je sélectionne une variable dans l'editeur mais une erreur me dit 'selection invalid'...

2 questions dans ce cas..

Methodes pour creer des getters et setters depuis une selection dans l'editeur ?

Je sais (car je l'ai déjà fait) qu'il est possible que l'éditeur génére la création de variables locales ou de l'objet en selectionnant des arguments du constructeur ou d'une fonction...et meme de les attribuer aux variables générés pour par exemple les initialiser lors de l'appel au constructeur

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
class {
type this.arg1_généré //généré par l'éditeur
type this.arg2_généré //généré par l'éditeur
Constructeur ( type arg1,type arg2)
{
this.arg1_généré=arg1;
this.arg2_généré=arg2
}

en général la création met souvent un attriobut privatre à ces variables...

merci de ce rafraichissement de mémoire...un reset doit etre passé par là

[afrikha]

Comment générer les getters et setters d'une classe ?

[vbrabant]

En effet. On a mis cela dans la FAQ car ceux qui viennent d'Eclipse sont généralement perdu. Tu viens encore une fois de le démontrer.

Vincent

[Ecosmose]

Merci vous !

je n'avais en effet chercher que dans le forum avec la fonction recherche...

[gifffftane]

Et pour faire l'inverse ? Pour transformer une interface de getters et setters en classe en rajoutant les champs et en transformant tous les appels ?

[Ecosmose]

La tu dois surement avoir une idée derrière la tete mais laisse te dire que ce n'est pas une forme de programmation idéale que tout programmeur s'efforce de s'appliquer...

en effet, dans une classe on préférera utiliser les methodes getx() setx() pour agir sur les variables ...et pourquoi utiliser cette manière plutot que d'agir sur les variables.et bien pour plus de flexibilité et de possibilité de changement lors de modif sur une prog. en effet lors d'appel herité ou encore dans les interactions entre plusieurs classe et une interface par exemple, il sera beaucoup plus facile de modifier les actions à effectuer sur la variable que de le faire directement dans la classe d'appel...je m'explique

Lorsque tu utilise des interfaces, elles font appel aux fonctions du meme nom des classes appelées...(dans notre exemple, les get et les set mais cela peut etre aussi les fonctions de gestion d'evenements comme une interface 'ecouteur'). une inteface pourra de cette manière lancer les fonction du mêm e nom mais de plusieurs classes différentes. Si chaque classe ou chaque objet doit avoir un comportement différent selon cette fonction, il te saura facile d'appliquer une code différent pour chaque classe (et donc pour chaque fonction) plutot que de detecter quelle classe est appelé et faire un switch pour savoir que faire sur la variable dans la classe appelante...

en gros je ne sais pas pourquoi tu désires faire le raisonnement inverse a moins que tu n'ai qu'une interface et que tu désires créer la classe inexistante...mais en général on fait l'inverse..

dans ce cas la une méthode qui pourrait marcher...c'est copier le code de l'interface ou encore mieux de la classe qui a générée l'interface puis de générer les variables...puis de redefinir si il faut les méthodes en question...normalement après la copie, des erreurs d'inexistance des variables devraient apparaitre de la il te sera facile de les créer (ptite ampoule rouge)...

voila je pense que je n'ai saisi ton problème qu'a la fin du post mais si ca a pu t'aider ou aider d'autre personne je laisse le début

[Ecosmose]

j'enleve le résolu pour que des gens viennent te donner de l'aide..

[n!co]

Il y a aussi la fonction Override Methods du menu source dans la barre de menu.
C'est utile pour générer n'importe qu'elle méthode de la classe parente sans que ce soit obligatoirement des méthodes abstraites, puis y a des options supplémentaire comme la génération de la doc, ...

[gifffftane]

C'est à dire que effectivement je fais l'inverse de tout le monde. Mais, des fois, je fais aussi comme tout le monde.

J'ai fait le raisonnement suivant. Il est franchement barbant d'écrire une interface avec des getters et des setters, puis d'écrire la classe correspondante, parce qu'il faut bien matérialiser l'interface.

Alors j'ai écrit une petite classe qui simule automatiquement n'importe quelle interface avec ses accesseurs. Je n'écris plus que l'interface, la classe se crée à la volée.

Cela marche bien, sauf que, au bout d'un moment, lorsque le programme prend de l'ampleur, il devient nécessaire de concrétiser vraiment la classe, pour assumer les traitements spécifiques (et imprévus) qui ne manquent pas d'apparaître.

Et c'est là que je transforme mon interface en vraie classe...

Mais ne vous inquietez pas, il y a aussi beaucoup de cas où je crée des interfaces pour me donner les moyens de diversifier la réalisation d'un contrat.

[Ecosmose]

d'ac pour le raisonnement de la création barbante d'interface mais je ne vois pas pourquoi tu crées d'abord tes interfaces avant les classes vu que les interfaces sont des passerelles de communication entre classe...c'est comme parler sans propos , comme des mouvements de bouche sans que les mots sortent...

sinon bien ouej nico pour le override c'est ce qui correspond je pense au besoin de gif

[gifffftane]

d'ac pour le raisonnement de la création barbante d'interface mais je ne vois pas pourquoi tu crées d'abord tes interfaces avant les classes vu que les interfaces sont des passerelles de communication entre classe...c'est comme parler sans propos , comme des mouvements de bouche sans que les mots sortent...

Mais oui c'est presque ça...

Au début, je repère un ensemble de valeurs qui correspondent à un traitement. Mais je ne sais pas toujours à quoi il correspond, ni même quel est son contour.

La solution est soit d'insérer toutes ces valeurs dans une classe existante, même si ça correspond pas tout à fait, soit de créer une classe avec que des accesseurs en supposant que, plus tard, cela devienne plus solide.

C'est dans le dernier cas que je me place ici. Créer simplement l'interface, avec un système pour créer la classe à la volée, me permet d'attendre au mieux que les choses prennent plus de maturité.

[n!co]

Pour finir avec le refactoring, bien que vous avez deja surement vu ces fonctions mais sait on jamais, il ya Extract Interface et Extract SuperClass dans le menu Refactor du clic droit, qui respectivement permet de créer une interface ou une classe mere sur certaines bases de la classe courante !

Par contre, je ne pige rien a votre discussion
Juste qu'une interface, soit tu la crées, soit on t'oblige à l'utiliser
Dans le premier cas, il est souvent intéressant de d'abord créer l'interface (pour les test unitaire par exemple) et de t'obliger à l'utiliser.

n!co