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 de dominio. Sin embargo, impiden el uso de patrones decoradores y compuestos, que también es común en este tipo de jerarquía.

Especialmente, probablemente nadie quiera implementar un decorador / compuesto para cada combinación posible de estas interfaces, por lo que la mayoría de las veces implementan todas las interfaces opcionales y utilizan la verificación de tipo para reenviar selectivamente las llamadas, lo que anula el propósito de tener interfaces separadas.

Una alternativa, que utiliza el marco de Java Collection, es incluir todas las operaciones en el tipo base y simplemente llenarlas 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 de columnas anulables en el mundo de la base de datos. ¿Hay algún argumento fuerte contra el último enfoque más práctico?

java design-patterns interfaces

— billc.cn
fuente

¿Estás limitado a Java o JVM? Porque Scala tiene esto perfectamente resuelto

— Frank

@Frank Me gustaría poder usar Scala o cualquier lenguaje que tenga rasgos, pero desafortunadamente, usar Java 8 ya es un gran salto para mi empresa ...

— billc.cn

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 tanto para los decoradores como para las clases que envuelven, independientemente de interfaz que implementan, que tiene un método declarado (usando 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 nulo en lugar de pasar la solicitud, ya que no hay ningún lugar para pasarla en este caso.

— Jules
fuente

Solución muy interesante. (Finalmente he añadido un getWrappedInstance()método para mi jerarquía de tipos de hacer algo similar Wish He pensado en esto..)

— billc.cn

1

El desafío con la alternativa es que hace que agregar / cambiar / eliminar características opcionales sea más difícil. 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 puede mitigarse un poco si hay un valor predeterminado razonable, como un no operativo, por lo que solo los subtipos que admiten la función deben anular 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. De lo contrario, el mantenimiento puede comenzar a ser 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 puede ser complicado en su situación, ya que un solo objeto puede implementar múltiples interfaces, pero aún podría ser factible con algunas modificaciones.

— cbojar
fuente