Discussion :

[fang44z]

Bonjour/Bonsoir à vous,

Je suis débutant en Java et je viens de commencer le cour sur les classe abstraite et les interface. Bon jusque là j'ai cru comprendre comment tout cela fonctionnait, j'ai donc décidé de m’entraîner de mon coté, et je me suis rendu compte que je suis un peux largué au final...

Je m'explique j'ai voulu m’entraîner en créant des robots qui ont différentes fonctions, un robot de combat cac, un distant, un healer, ect... Tous ses objets sont enfants de la super classe (abstraite) Robot, et donc j'aimerai crée une méthode pour le healer qui fait que ca ajoute 100 point de vie à la cible et retire 10 points de mana au healer. Dans mon esprit je pensais que crée cette méthode dans le classe enfant prévu à cet effet aurait suffit... Seulement non ca ne fonctionne pas, le seul moyen que j'ai trouvé pour réussir a été de créer cette méthode dans la superclass.

Le résultat fonctionne sauf que ma question est du coup... Les classe enfants ne peuvent-ils vraiment pas crée de méthode ? Parce que ca voudrais dire qu'il est impossible de faire ne serait-ce qu'un simple getter/setter, et du coup je suis obligé de crée chaque variables dans la superclass, et donc les autre objet qui ne se serviront pas du tout de cette variable n'auront pas le choix de devront être instancié avec(un guerrier avec du mana par exemple). Et ce n'est pas ce que je veux.

J'ai essayé de crée une interface pour crée ces méthode et l'implémenter à mon healer mais rien n'y fais non plus...

Du coup j'ai essayé quelque chose comme ca:

Code :

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

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
27
import Comportements.Healing;
 
public class RobotHeal extends Robot implements BuildHealer{
    private int mana;
    public RobotHeal(String type, int healthP, int shieldP, int speedB, int mana) {
        super(type, healthP, shieldP, speedB);
        this.support = new Healing();
        this.mana = mana;
    }
    @Override
    public void setMana(int mana) {
        this.mana = mana;
    }
    @Override
    public int getMana() {
        return mana;
    }
    @Override
    public void giveHeal(Robot x, Robot y){
        int healing = 100;
        x.setHealthP(healing+=x.getHealthP());
        y.setMana(y.mana-=10);
        System.out.println("Les HP de "+x.type+" sont désormé à "+x.getHealthP()+"HP");
        System.out.println(y.type+" a perdu 10 de mana en guerrissant "+x.type);
        System.out.println("Ses point de mana sont désormé de "+y.getMana());
    }
}

Bon, malheureusement impossible d’accéder à ces méthode via mon main surtout que dans ma méthode les setter et getter sont en rouge donc non accessible.
Du coup comment créer un code similaire sans devoir faire une classe parent rempli de méthode et de variable pour chacun des objet enfant... Et si c'est impossible et que je n'ai pas le choix que de tout faire dans ma classe parent, je devrait donc crée un constructeur pour chacune des classe ?(afin d'éviter de me retrouver avec un guerrier avec du mana par exemple) Et surtout à quoi servent les interface si ce n'est pas pour crée des méthodes pour des classe déjà hérité ?

Merci pour vos futurs réponses, je sais que mes questions ne sont pas super claire c'est assé compliqué d'expliquer quelque chose que je ne comprend pas, n'hésitez pas à me demander plus de détail si vous ne m'avez pas compris

[thelvin]

Hello,

eh oui c'est compliqué au début, le polymorphisme.

Les classes enfants ont parfaitement le droit de créer leurs propres méthodes (d'ailleurs tu n'as pas d'erreur de compilation quand tu mets une nouvelle méthode dans une classe enfant).

Mais si elles le font, ça ne regarde pas leurs classes parents. Ça les regarde juste elles. Ce qui concerne les classes parents, c'est quand les classes filles redéfinissent les méthodes des classes parents.

Concrètement ça veut que tu peux tout à fait faire :

Code :

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

1
2
RobotHeal robot = new RobotHeal("meat", 100, 100, 100, 20);
robot.heal(otherRobot, robot); // au passage, un robot healer devrait pas avoir besoin qu'on lui dise que c'est lui qui heal. Qui d'autre ? Tu devrais enlever le paramètre y.

Par contre tu peux pas faire :

Code :

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

1
2
Robot robot = new RobotHeal("meat", 100, 100, 100, 20); // ça compile, car un healer est un robot
robot.heal(otherRobot, robot); // ça compile pas, parce que tous les robots ne peuvent pas soigner. Seuls les healers peuvent healer

Parce que si tu pouvais, tu pourrais aussi faire :

Code :

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

1
2
Robot robot = new RobotWarriorWithASwordAndNoMana(); // ça compile, car un warrior est un robot
robot.heal(otherRobot, robot);

et ça marche pas de heal avec une grosse épée qui est pas enchantée pour heal.
Le heal c'est réservé aux healers.

Du coup pourquoi on peut ajouter des méthodes dans les classes enfants, eh bien pourquoi pas ? Ça ne servirait pas à grand-chose de l'empêcher...

Mais comment utiliser les interfaces dans ton truc de robots eh ben... Le polymorphisme c'est pas toujours la solution. Peut-être qu'avec tes robots les interfaces ça sert pas à grand-chose. Ça aurait peut-être plus de sens de garder les healers quelque part, les warriors quelque part ailleurs et les rogues encore à un autre endroit.

Mais si tu veux une idée de comment utiliser les interfaces, tu pourrais faire comme ça :

L'interface Robot déclare une méthode :

Code :

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

void doYourJobThisTurn(WorldState state);

et la classe RobotHealer doit :
- chercher si des robots ont besoin d'un heal
- faire un heal sur ceux qui en ont besoin.

La classe RobotWarrior doit chercher l'ennemi qui mourra le plus vite et abattre son épée dessus.

La classe RobotRogue doit faire les poches des passants qui regardent le combat.

[fang44z]

Ok...

Alors si j'ai bien suivis je me prend le choux simplement à cause du fait du polymorphisme. C'est à dire que vu que j'ai fait comme ceci:

Code :

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

1
2
 
Robot robot1 = new RobotClasse(...);

Alors les méthode ne sont pas accessibles... Du coup pour que ce soit un peux plus propre je garde donc ma classe parente, et les autres classes toujours extends de "Robot", mais j’instancie avec la bonne classe, pour avoir les bon constructeurs, les bonnes méthodes ect...

Alors soit je suis bête soit j'était trop focus sur une seule et même solution pour ne pas voir que la bonne solution finalement est sous mes yeux depuis le début...

Et pour en revenir aux interfaces vu qu'une interface est toujours abstraite ca veux dire donc que je doit réécrire la méthode pour chacune des classe qu'elle implémente. Donc le plus malin serait de créer une interfaces où chacune des classes pourrait partager une/plusieurs de ses méthodes? Ce serait donc plus pratique que de la faire vie la classe mère qui est déjà abstraite?

Parce qu'il y a ca aussi qui me dérange un peux... Vu que je peux déjà crée des méthode dans la classe mère puis les réécrire sur celles qui en héritent, pourquoi donc crée des interfaces ?

Cependant je te remercie Thelvin pour ta réponse vraiment très claire et précise

[thelvin]

Eh bien en fait, il faut savoir distinguer deux choses utiles qui sont différentes.

- d'une part le fait pour plusieurs classes d'avoir un ancêtre commun, sans pour autant que l'ancêtre commun ne leur impose quoi que ce soit. C'est ce que proposent les interfaces.
- d'autre part le fait pour plusieurs classes d'une même hiérarchie de partager automatiquement du code commun. C'est ce que proposent les classes parentes, dont les enfants héritent du code contenu.

Et ces deux choses utiles, on a souvent besoin des deux. Résultat ce qui arrive souvent c'est qu'on fait :
- une interface qui servira de type racine.
- une classe mère qui implémente l'interface, et qui pourra éventuellement être abstraite.
- des classes filles de la classe mère (qui héritent donc du fait que la classe mère implémente l'interface... Et de tout le reste de la classe mère).

=> Ce qui permet d'avoir les deux avantages.

Mais donc quel est l'intérêt des interfaces, ces choses dont il est garanti qu'elles sont intégralement abstraites ?
Eh bien grosso-merdo il y en a deux :

- d'abord le "concept de programmation par interface." C'est lorsqu'une partie de ton programme reçoit un objet qui implémente une certaine interface, et se sert de cet objet à travers les méthodes de l'interface.

Ça n'a l'air de rien mais du coup mais du coup, quand tu dois fournir l'objet à cette partie du programme, eh bien tu es 100% libre de fournir ce que tu veux.

Si tu connais une classe A qui implémente cette interface, et que cette classe te convient bien, tu peux fournir une instance de A.
Si tu connais plutôt une classe B, tu peux fournir une classe B.
Et si les classes qui existent déjà ne te semble pas adaptées et que tu ne vois rien de bon à reprendre d'elles, rien de t'empêche d'écrire une classe C de zéro.

Ce dernier cas autorise des choses comme un patron décorateur automatisé en utilisant une bibliothèque de gestion automatique de décorateurs, comme Spring AOP.
Ou bien de faire des tests unitaires dans lesquels tu vas tester ton bout de programme, mais pas l'objet qu'il utilise. A la place de cet objet tu fournis une façade qui implémente l'interface et qui quand on l'appelle, répond ce qu'elle est préprogrammée à répondre au lieu de faire des choses par elle-même.

Ça permet donc de choisir très librement en fonction de la situation si tu veux faire ça :

Code :

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

myProgramPiece.setSortingAlgorithm(new SelectionSort());

ou ça :

Code :

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

myProgramPiece.setSortingAlgorithm(new BubbleSort());

ou ça :

Code :

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

myTestedProgramPiece.setSortingAlgorithm(new FakeSortingAlgorithm());

De manière générale, programmer par interface est un outil de génie logiciel dont l'efficacité est connue des professionnels. Elle marche extrêmement bien avec Spring et c'est pas pour rien qu'il a reçu une telle adoption dès ses débuts (malgré les horribles fichiers de configuration XML).

- deuxième intérêt, la possibilité d'implémenter plusieurs interfaces par une même classe. Ce qui dans d'autres langages est le problématique héritage multiple, ici est plutôt du sous-typage multiple. Dénué de problème.

Le problème de l'héritage multiple c'est lorsque les différentes parties héritées entrent en conflit, sans même parler du triste cas de l'héritage en triangle : classe mère A. B hérite de A et C hérite aussi de A. D hérite de B et C. Concrètement, l'ordinateur ne va pas faire de miracle : l'héritage fournit des automatismes et tenter d'automatiser ce cas-là est autocontradictoire.

Alors qu'implémenter une ou plusieurs interfaces ne fait hériter d'aucun bagage : toute l'implémentation reste à faire, de manière donc parfaitement libre. Les interfaces n'ont pas de constructeur, dont on devrait donc se demander dans quel ordre les exécuter et comment gérer leurs inévitables conflits. Ni d'état interne, dont les constructeurs se doivent d'être les garants, et qui peuvent aussi se dupliquer ou se traîner comme des boulets.

- une note pour finir :

En fait, depuis Java 8 (donc un peu récent mais pas très), les interfaces ont le droit de définir du code qui pourrait être hérité en commun par les classes qui les implémentent.

C'est ce que l'on appelle les méthodes par défaut, des méthodes déclarées par des interfaces et pour lesquelles une implémentation est donnée, même si les classes qui implémentent ont toujours le droit de les redéfinir.

Ça ne permet pas autant de choses que des méthodes définies par une classe mère, parce que contrairement à une classe, une interface n'a pas d'état interne. Les méthodes par défaut ne peuvent donc rien faire d'autre qu'appeler d'autres méthodes. Ça a son utilité pour éviter de dupliquer du code, mais ça ne peut pas tout faire.