Falsification de méthodes abstraites à l'aide d'exceptions en Java

Question

On m'a posé cette question et je suis franchement perplexe :

Au lieu d'écrire des méthodes abstraites, nous pourrions essayer de les simuler avec des exceptions, comme ceci :

public int someMethod(int someparameter) {
    throws new RuntimeException("unimplemented");
}

Quel serait le but de cette opération et quelqu'un peut-il fournir un exemple de code pour une méthode abstraite que ce qui précède tente de simuler ?Toute aide est grandement appréciée.Merci.

Answer 1

Je peux penser à un cas d'utilisation (éventuellement) valide :Vous disposez d'une classe abstraite et d'un certain nombre d'autres classes tout au long de votre projet qui l'ont étendu.(Ou bien, la classe abstraite se trouve dans une bibliothèque open source, vous n'avez donc aucune idée des autres classes de l'univers qui pourraient en être étendues.) Vous trouvez maintenant qu'il est utile d'ajouter de nouvelles méthodes abstraites à cette classe.Mais si tu ajoutes abstract méthodes à la classe, cela interrompt toutes les autres classes qui l'ont déjà étendue, car ces classes doivent être modifiées pour contenir le remplacement des nouvelles méthodes.Je peux donc voir comment, dans certains cas, il pourrait être considéré comme plus faisable de les ajouter en tant que méthodes non abstraites et de leur demander de lever des exceptions juste au cas où un nouveau la classe qui l'étend utilise les nouvelles méthodes mais oublie d'écrire une méthode de remplacement.Il ne sera pas détecté au moment de la compilation, mais au moins il pourra l'être lors des tests.

Je ne suis pas sûr de la légitimité de cette raison, puisqu'il est également possible de définir une nouvelle classe abstraite NewImprovedWhatever qui étend l'ancienne, pour contenir les nouvelles méthodes.Cela peut cependant poser ses propres problèmes de maintenance.Je ne suis pas sûr.

J'ai remarqué que Java définit une classe abstraite java.net.SocketImpl, qui contient deux méthodes non abstraites, shutdownInput() et shutdownOutput(), dont l'implémentation par défaut consiste à lever une exception :

protected void shutdownInput() throws IOException {
  throw new IOException("Method not implemented!");
}

Les commentaires indiquent qu'ils ont été ajoutés dans la version 1.3, donc c'est peut-être la raison exacte pour laquelle cela a été fait de cette façon, c'est-à-direne pas nécessiter de modification d'autres classes déjà étendues SocketImpl.Mais je n'en suis pas sûr.

Dans tous les cas, une conception comme celle-ci serait sûrement un très mauvais code si la classe était conçue de cette façon à partir de zéro.Mais les bons concepts O-O que nous apprenons en classe ne sont pas toujours aussi bons en pratique lorsque le code existant doit être modifié.

Answer 2

J'ai parfois jeté InférendedOperationException deune méthode dont la fonctionnalité n'a pas encore été mise en œuvre.(Il y a aussi un NotymplementedException à Apache Commons , qui est une sous-classe de non-supposéOperationException.) Cela a toujours été conçu comme un espace réservé et un message à d'autres personnes utilisant la classe ou le service associé que la méthode n'est pas encore complète.Ce code ne s'est jamais rendu à la production, cependant.

Answer 3

Le but de le faire serait d'écrire à délibération de mauvais code .
Si on veut confondre ses lecteurs et veulent qu'ils ressentent l'agonie de passer à travers leur code, alors on écrit ce code.
Il montre également l'absence de compétences conçues dans le code.
Une API mal écrite aura un tel code.
Ne fais pas ça.