¿Es una buena práctica implementar dos métodos predeterminados de Java 8 en términos mutuos?

Question

¿Es una buena práctica implementar dos métodos predeterminados de Java 8 en términos mutuos?

14

Estoy diseñando una interfaz con dos métodos relacionados, similar a esto:

public interface ThingComputer {
    default Thing computeFirstThing() {
        return computeAllThings().get(0);
    }

    default List<Thing> computeAllThings() {
        return ImmutableList.of(computeFirstThing());
    }
}

Alrededor de la mitad de las implementaciones solo computarán una cosa, mientras que la otra mitad puede computar más.

¿Esto tiene algún precedente en el código de Java 8 ampliamente utilizado? Sé que Haskell hace cosas similares en algunas clases de tipos ( Eq por ejemplo).

El lado positivo es que tengo que escribir significativamente menos código que si tuviera dos clases abstractas ( SingleThingComputer y MultipleThingComputer ).

El inconveniente es que una implementación vacía se compila pero explota en tiempo de ejecución con un StackOverflowError . Es posible detectar la recursión mutua con un ThreadLocal y dar un error más agradable, pero eso agrega sobrecarga al código sin errores.

design java interfaces java8

pregunta Tavian Barnes 18.06.2015 - 21:12

1 respuesta

Lea otras preguntas en las etiquetas design java interfaces java8

¿Cómo se determina la precedencia en los punteros C? ¿Se debería favorecer la coherencia sobre la convención de programación?

score 16 · Accepted Answer

TL; DR: no hagas esto.

Lo que se muestra aquí es un código frágil.

Una interfaz es un contrato. Dice "independientemente del objeto que consigas, puede hacer X e Y". Tal como está escrito, su interfaz no hace ni X ni Y porque está garantizado para provocar un desbordamiento de pila.

Lanzar un Error o subclase indica un error grave que debería no ser atrapado:

Un error es una subclase de Throwable que indica problemas graves que una aplicación razonable no debe tratar de atrapar.

Además, VirtualMachineError , la clase principal de StackOverflowError , dice esto:

Se lanza para indicar que la máquina virtual de Java está dañada o se ha ejecutado de los recursos necesarios para que continúe operando.

Su programa no debe preocuparse por los recursos de JVM . Ese es el trabajo de la JVM. Hacer un programa que cause un error de JVM como parte de la operación normal es malo. Esto garantiza que su programa se bloqueará o obliga a los usuarios de esta interfaz a interceptar errores que no deberían preocuparse.

Puede que conozca a Eric Lippert de esfuerzos como emérito "miembro del comité de diseño de lenguaje C #". Habla sobre las características del lenguaje que empujan a las personas hacia el éxito o el fracaso: si bien esta no es una característica del idioma o parte del diseño del lenguaje, su punto es igualmente válido cuando se trata de implementar interfaces o usar objetos.

Recuerdas en The Princess Bride cuando Westley se despierta y encuentra él mismo encerrado en el hoyo de la desesperación con un albino ronco y el Siniestro hombre de seis dedos, el conde Rugen? La idea principal de un pozo de La desesperación es doble. Primero, que es un hoyo, y por lo tanto fácil de Caer en el trabajo, pero difícil de salir de. Y segundo, que Induce la desesperación. De ahí el nombre.

^{_{Fuente: C ++ y el hoyo de la desesperación}}

Tener una interfaz lanza un StackOverflowError de manera predeterminada empuja a los desarrolladores a Pit of Despair y es mala idea . En su lugar, empuje a los desarrolladores hacia el Pit of Success . Haga que sea fácil utilizar su interfaz correctamente y sin bloquear la JVM.

Delegar entre los métodos está bien aquí. Sin embargo, la dependencia debe ir en un solo sentido. Me gusta pensar en la delegación de métodos como un gráfico dirigido . Cada método es un nodo en el gráfico. Cada vez que un método llama a otro método, dibuje un borde del método de llamada al método llamado.

Si dibujas un gráfico y te das cuenta de que es cíclico, es un olor de código. Ese es un potencial para empujar a los desarrolladores en el hoyo de la desesperación. Tenga en cuenta que no se debe prohibir categóricamente, solo que se debe tener precaución . Los algoritmos recursivos específicamente tendrán ciclos en el gráfico de llamadas: eso está bien. Documentarlo y advertir a los desarrolladores. Si no es recursivo, intenta romper ese ciclo. Si no puede, averigüe qué entradas podrían causar un desbordamiento de la pila y mitiguelas o documéntelas como último caso, si nada más funciona.