Setter et Getter dans une Interface

Bonjour les amis !!

Quelqu'un peut m'aider à comprendre s'il est obligatoire de rajouter des setters et des getters dans une interface pour faire l'injection de dépendance ?

Je m'explique, supposons qu'une classe implémente une interface. Cette interface ne possède pas de getters et de setters mais la classe quant à elle possède des getters et des setters.

Pour faire de l'injection de dépendance, Spring utilise l'interface et les setters de la classe. Comment cela est possible si les setters ne sont pas définis dans l'interface ?

Merci d'avance pour vos questions

Salut,

Je ne connais pas très bien Spring, mais j'imagines qu'il fait de la réflexion pour ce genre de choses, du coup peu importes les interfaces ou les classes mères, il cherche une propriété de nom xxx (=> getXxx() et setXxx()) dans l'instance du bean donc dans les méthodes du bean qui sont composées des méthodes de la classe filles + les méthodes de chaque classe mère.

Je pense que cette réponse apporte une valeur ajoutée à ma curiosité. Merci pour cet éclairage. Cependant, est-ce que cela répond à la question que j'ai posée plus haut.

l'injection se fait par introspection, pas par compilation, donc les interfaces implémentées, c'est pas ses affaire, il a concrètement une instance sur laquel on lui dit, "va mettre à X la propriété y", il va chercher par introspection une méthode setY(), et l'appeler, toujours par introspection. Avec ce genre de truc on peux même appeler des setters / getters qui sont privés!

Merci beaucoup pour vos réponses !

Pour être plus claire dans ma réponse, supposons que j'ai une interface dont le nom est Linterface puis une classe LaClasse qui implémente cette interface

Code de l'interface :

Code:

---

1 2 3 4 5 6 7 8

public interface Linterface {   String getQqChose (int entier);   void setQqChose(String valeur);   }

---

Code de la classe :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

public class LaClasse implements Linterface{ @Autowired String pourlinjection = null; @Override public String getQqChose(int entier) { // TODO Auto-generated method stub return null; } @Override public void setQqChose(String valeur) { // TODO Auto-generated method stub } public String getPourlinjection() { return pourlinjection; } public void setPourlinjection(String pourlinjection) { this.pourlinjection = pourlinjection; } }

---

Ma quesstion est de savoir s'il faut définir forcement le setter dans l'interface comme ceci :

Code:

---

1 2 3 4 5 6 7 8 9

public interface Linterface { String getQqChose (int entier); void setQqChose(String valeur); public void setPourlinjection(String pourlinjection); }

---

Merci d'avance pour vos réponses.

comem déjà dit, a priori, Spring s'en fout. Et si t'as un doute, suffit de tester, ça prend quelques minutes ;)

Oui, je suis d'accrod avec toi tchize_, j'ai fait le test et ça marche très bien !!!!
Mais pour mes tests unitaires avec JUnit et EasyMock, j'utilise les interfaces. Seulement, lorsque je crée un simulacre avec EasyMock par le biais d'une interface, j'ai besoin du setter de la propriété définie dans la classe.
Le setter est créé dans la classe, à partir de la propriété de la classe qui implémente l'interface que j'utilise pour crée mon simulacre.
La question : ce setter qui est dans la classe que Spring utilise pour faire son injection, est-il dans l'orthodoxie du "code propre" de définir ce setter dans l'interface ?

Merci d'avance !!

dans l'interface, on met ce qui concerne l'interface, c'est à dire les méthodes que devrait implémenter tout classe utilisant l'interface. A toi donc de voir si cette méthode a du sens pour l'interface.

Par exemple si un classe Chien implémente une interface AnimalDeCompagnie, et que tu as un setteur dans chien, utilisé par spring setMarqueDePateePourChienPreferee(), information qui serait par exemple utile à une méthode getCoutMensuelNouriture, ca a un sens d'avoir getCoutMensuelNouriture dans l'interface, mais pas d'avoir setMarqueDePateePourChienPreferee.

Dernière chose, on ne modifie pas une classe/interface pour pouvoir la tester plus facilement, en général. On la modifie uniquement parce qu'il y a un besoin concret du code productif derrière.

Merci beaucoup ! ton aide m'a été d'une bonne utilité !!

résolu.