Interfaces Java et Design Pattern

Bonjour à tous !

Étant tout nouveau en java et sur le forum, je me pose une question qui peut peut-être sembler idiote ou bizarre.

En gros l'intérêt d'une interface est de définir ce qu'on va demander de faire aux objets issus d'une classe qui implémente cette interface.

Du coup, mettons que j'ai une superclasse Vehicule et des classes héritées Moto, Voiture, Tracteur, Batmobile et Kart
Et je me dis que j'aimerais que certains véhicules (mettons Batmobile et Kart) soient capables de lancer une attaque (la Batmobile peut lancer des missiles et le Kart des carapaces). Du coup je crée une interface du type

Code:

---

1 2 3 4

public interface Attaquant { public void attaquer(); }

---

et je modifie mes classes Batmobile et Kart pour
1 - modifier la déclaration et rajouter "implements Attaquant" (A partir de là, toute classe qui implémente Attaquant DOIT avoir une méthode attaquer() sinon Eclipse m'engueule)
2 - redéclarer et définir en leur sein la méthode this.attaquer();

Du coup je suis content.

Mais QUESTION: Si jamais je change d'avis et que je ne veux plus que le kart puisse attaquer, le fait de simplement supprimer l'implémentation d'Attaquant chez la classe Kart (en virant le "implements Attaquant") ne m'empêche pas d'appeler la méthode attaquer() définie au sein de la classe (je peux faire monKart.attaquer(); sans soucis).
Du coup, la création d'une interface m'oblige certes à implémenter des méthodes dans toute classe qui implémente mon interface, en revanche ELLE NE M'IMPOSE PAS DE SUPPRIMER CES METHODES DE MA CLASSE SI JE LUI DESIMPLÉMENTE MON INTERFACE (en virant le "implements Attaquant").

Savez-vous comment avoir cette "flexibilité" dans l'autre sens ?

Merci beaucoup pour votre lecture et vos réponses :)

Une interface est un contrat, les objets qui implémentent l'interface doivent implémenter les méthodes du contrat.
Mais une classe java peut implémenter ces méthodes sans pour autant répondre au contrat, il n'y a pas de réciprocité possible là.

L'intérêt de l'interface est de pouvoir "voir" un objet non pas sous forme de classe mais sous forme de "contrat".

Imaginons une interface "déplaçable", beaucoup d'objets peuvent être déplacés, ces déplacements nécessitent des actions très différentes en fonction de la nature de l'objet (un avion ne va pas agir de la même manière qu'un hélicoptère, ni qu'une voiture ou une moto pour les déplacements 2D)
Par contre pour un contrôleur de flux, la manière importe peu, lui veut que le "déplaçable" avance, recule, tourne à droite ou à gauche etc...
S'il devait se préoccuper du comment, il devrait connaître toutes les classes correspondant à tous les objets de sa liste à gérer (et caster).
Avec l'interface, il voit tous les objets de sa liste sous la forme de déplaçable et sait qu'il peut leur demander les actions, quelles que soient les façons effectives de faire les déplacement.

Bref, si l'objet n'implémente plus l'interface, il n'en a pas moins le droit d'implémenter n'importe quelle méthode.

En espérant t'avoir éclairé un peu ;)

J'ai l'impression que tu reflechis de maniere trop theorique et pas assez pratique.
En pratique, si tu instancies un objet qui implemente une interface, à un moment, tu vas appeler une fonction qui utilise l'interface en question. Typiquement, si tu crees une classe Kart qui implemente ton interface Attaquant, tu vas appeler une fonction genre void enregistreAttaquant(Attaquant attaquant);.

C'est elle qui va peter quand tu supprimeras la dependance.

Si ce qui te chagrine, c'est le code mort, il existe une annotation @Override qui permet d'indiquer que la fonction dont depend l'annotation surcharge une fonction d'une autre classe/interface. Si tu supprimes la dependance, ton IDE t'indiquera qu'il ne trouve pas la fonction surchargée.

Mouarf parfait vous êtes top !
Merci beaucoup pour vos conseils :) !