Falsificar métodos abstractos usando excepciones en Java

Question

Me han hecho esta pregunta y, francamente, estoy perplejo:

En lugar de escribir métodos abstractos, podríamos intentar falsificarlos con excepciones, como esta:

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

¿Cuál sería el propósito de hacer esto? ¿Alguien puede proporcionar un ejemplo de código para un método abstracto que lo anterior intenta falsificar?Cualquier ayuda es muy apreciada.Gracias.

Answer 1

Puedo pensar en un caso de uso (posiblemente) válido:Tiene una clase abstracta y varias otras clases a lo largo de su proyecto que la ampliaron.(O la clase abstracta está en una biblioteca de código abierto, por lo que no tiene idea de qué otras clases en todo el universo podrían extenderse a partir de ella). Ahora, encontrará que es útil agregar nuevos métodos abstractos a esta clase.Pero si agregas abstract métodos a la clase, esto rompe todas las demás clases que ya la han extendido, porque esas clases deben cambiarse para contener anulaciones para los nuevos métodos.Entonces puedo ver cómo, en algunos casos, podría considerarse más factible agregarlos como métodos no abstractos y hacer que arrojen excepciones en caso de que nuevo La clase que lo extiende usa los nuevos métodos pero se olvida de escribir un método principal.No se detectará en tiempo de compilación, pero al menos podría detectarse durante las pruebas.

No estoy seguro de cuán legítima sea esta razón, ya que también es posible definir una nueva clase abstracta. NewImprovedWhatever que extiende el antiguo, para contener los nuevos métodos.Sin embargo, eso puede plantear sus propios desafíos de mantenimiento.No estoy seguro.

Me di cuenta de que Java define una clase abstracta. java.net.SocketImpl, que contiene dos métodos no abstractos, shutdownInput() y shutdownOutput(), cuya implementación predeterminada es generar una excepción:

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

Los comentarios indican que se agregaron en 1.3, así que quizás esa sea la razón exacta por la que se hizo de esta manera, es decir.no requerir modificación de otras clases que ya se extendieron SocketImpl.Pero no lo sé con seguridad.

En cualquier caso, un diseño como este seguramente sería un código realmente malo, si la clase se diseñara de esa manera desde cero.Pero los buenos conceptos OO que aprendemos en clase no siempre son tan buenos en la práctica cuando es necesario modificar el código existente.

Answer 2

A veces he tirado insoportedopedoperaciónExcepción deUn método cuya funcionalidad aún no se ha implementado.(También hay una NOIMPLEMENTEDEXCEGE EN APACHE COMOUNES que es una subclase de la excepcepción sin apoyo.) Esto siempre se entendió como un marcador de posición y un mensaje para otros utilizando la clase o servicio relacionado que aún no está completo.Dicho código nunca llegó a la producción, sin embargo.

Answer 3

El propósito de hacerlo sería escribir a propósito mal código .
Si uno quiere confundir a sus lectores y quiere que sientan la agonía de pasar por su código, entonces uno escribe dicho código.
También muestra la falta de habilidades de diseño en el código.
Una API mal escrita tendrá dicho código.
No hagas eso.