Características opcionales: método predeterminado o interfaz separada

8

Las interfaces dedicadas parecen ser una buena manera de exponer las características opcionales en una jerarquía de tipos específica del dominio. Sin embargo, impiden el uso de decorador y patrones compuestos, lo que también es común en este tipo de jerarquía.

Especialmente, probablemente nadie quiera implementar un decorador / compuesto para cada posible combinación de estas interfaces, por lo que la mayoría de las veces implementa todas las interfaces opcionales y utiliza la verificación de tipos para reenviar las llamadas de manera selectiva, lo que anula el propósito de haberse separado. interfaces.

Una alternativa, que utiliza el marco de Java Collection, es incluir todas las operaciones en el tipo base y simplemente rellenarlas con implementaciones ficticias. Los métodos predeterminados en Java 8 facilitan aún más este uso.

En cierto modo, esto se siente como el debate sobre columnas anulables en el mundo de la base de datos. ¿Hay algún argumento fuerte contra el último enfoque más práctico?

    
pregunta billc.cn 24.07.2015 - 17:10

2 respuestas

2

Una solución a este problema que he usado en el pasado (donde un gran número de decoradores agrega instalaciones a una base relativamente simple, con muchas interfaces posibles) es tener una clase base para los decoradores y las clases que envuelven , independientemente de la interfaz que implementen, que tiene un método declarado (utilizando la sintaxis de Java):

    public <T> T findImplementation (Class<T> cls) {
       if (cls.isAssignableFrom(getClass())
           return cls.cast(this);
      return wrapped.findImplementation (cls);
   }

Obviamente, las implementaciones sin decorador devuelven un valor nulo en lugar de pasar la solicitud, ya que no hay ningún lugar para pasarla en este caso.

    
respondido por el Jules 29.08.2015 - 16:08
1

El desafío con la alternativa es que hace más difícil agregar / cambiar / eliminar características opcionales. Por ejemplo, si agregamos una nueva característica opcional, ahora tenemos que cambiar la clase base y luego cambiar todas las subclases para agregar la característica o la no característica. Esto se puede mitigar de alguna manera si existe un valor predeterminado razonable, como un no-op, por lo que solo los subtipos que admiten la función deben reemplazar las partes necesarias. Si estas características opcionales son pocas, relativamente estables y es poco probable que cambien, simplemente agregarlas al supertipo podría ser suficiente. Si no es así, entonces el mantenimiento puede comenzar a volverse difícil de manejar.

El patrón de diseño más común para recuperar el tipo de supertipo es el patrón de visitante . Esto podría ser complicado en su situación, ya que un solo objeto puede implementar múltiples interfaces, pero aún podría hacerse con algunas modificaciones.

    
respondido por el cbojar 29.07.2015 - 21:36

Lea otras preguntas en las etiquetas