¿Qué es un buen diseño para una interfaz con componentes opcionales?

Question

Supongamos que tengo una interfaz que soporta unas pocas operaciones posibles:

interface Frobnicator { 
    int doFoo(double v); 
    int doBar(); 
} 

Ahora, algunos casos sólo apoyará una u otra de estas operaciones. Ellos pueden apoyar ambos. El código del cliente no necesariamente lo sabrá hasta que obtenga uno de la fábrica relevante, a través de la inyección de dependencia, o desde donde obtenga instancias.

Veo algunas maneras de manejar esto. Una, que parece ser la táctica general tomada en la API de Java, es simplemente tener la interfaz como se muestra arriba y tener métodos no compatibles aumentar UnsupportedOperationException. Esto tiene la desventaja, sin embargo, de no ser rápido: el código del cliente no puede decir si doFoo funcionará hasta que intente llamar al doFoo.

Esto podría ser aumentado con supportsFoo() y supportsBar() métodos, definidos para devolver verdadero si el método correspondiente do funciona.

Otra estrategia es factorizar los métodos doFoo y doBar en los métodos FooFrobnicator y BarFrobnicator, respectivamente. Estos métodos devolverían null si la operación no es compatible. Para mantener el código de cliente de tener que hacer instanceof cheques, defino una interfaz de Frobnicator como sigue:

interface Frobnicator { 
    /* Get a foo frobnicator, returning null if not possible */ 
    FooFrobnicator getFooFrobnicator(); 
    /* Get a bar frobnicator, returning null if not possible */ 
    BarFrobnicator getBarFrobnicator(); 
} 

interface FooFrobnicator { 
    int doFoo(double v); 
} 

interface BarFrobnicator { 
    int doBar(); 
} 

Alternativamente, FooFrobnicator y BarFrobnicator podría ampliar Frobnicator, y los métodos get* posiblemente ser renombrado as*.

Un problema con esto es nombrar: el Frobnicator realmente no es un frobnicator, es una forma de obtener frobnicators (a menos que use el as* nombrando). También es un poco difícil de manejar. La nomenclatura puede ser más complicada, ya que el Frobnicator se recuperará de un servicio FrobnicatorEngine.

¿Alguien tiene alguna idea de una solución buena, preferiblemente bien aceptada para este problema? ¿Hay un patrón de diseño apropiado? El visitante no es apropiado en este caso, ya que el código del cliente necesita un tipo particular de interfaz (y preferiblemente debe fallar rápido si no puede obtenerlo), en lugar de despachar el tipo de objeto que obtuvo. Si se soportan o no características diferentes puede variar en una variedad de cosas: la implementación de Frobnicator, la configuración en tiempo de ejecución de esa implementación (por ejemplo, admite doFoo solo si hay algún servicio de sistema disponible para habilitar Foo), etc.

Actualización: La configuración en tiempo de ejecución es la otra llave inglesa en este negocio. Es posible transportar los tipos FooFrobnicator y BarFrobnicator para evitar el problema, especialmente si uso más los Guice-modules-as-configuration, pero introduce complejidad en otras interfaces circundantes (como la fábrica/constructor que produce Frobnicators). en primer lugar). Básicamente, la implementación de la fábrica que produce frobnicators se configura en tiempo de ejecución (ya sea a través de propiedades o un módulo de Guice), y quiero que sea bastante fácil para el usuario decir "conectar este proveedor de frobnicator con este cliente" . Admito que es un problema con posibles problemas de diseño inherentes, y que también podría estar pensando demasiado en algunos de los problemas de generalización, pero prefiero una combinación de lo menos feo y lo menos asombroso.

Answer 1

Creo que tienes un problema si usted está diciendo que la clase implementa la interfaz FooImpl Foo, pero que en realidad no implementar todas Foo. Se supone que la interfaz es un contrato que indica qué métodos implementa la clase implementadora (como mínimo).

Si algo llama a FooFactory para obtener un objeto Foo, el objeto debería ser capaz de hacer lo que hace Foos.

Entonces, ¿a dónde vas desde allí? Sugeriría que tu idea de composición sea buena, usando la herencia un poco menos.

La composición funcionaría exactamente como la tiene con los métodos getFooFrobnicator() y getBarFrobnicator(). Si no le gusta que su Frobnicator en realidad no lo haga, llámelo FrobnicatorHolder.

Herencia tendría su Frobnicator conteniendo solo los métodos que tienen todos los Frobnicators, y las subinterfaces tendrían los métodos adicionales.

public interface Frobnicator{ 
    public void frobnicate(); 
} 

public interface FooFrobnicator{ 
    public void doFoo(); 
} 

public interface BarFrobnicator{ 
    public void doBar(); 
} 

A continuación, podría utilizar if (frobnicator instanceof FooFrobnicator) { ((FooFrobnicator) frobnicator).doFoo() } y la vida sigue.

Favorecer la composición por herencia. Estarás más feliz.

Answer 2

¿Qué le parece simplemente agregar métodos vacíos de no implementación en lugar de arrojar UnsupportedOperationExceptions? De esta forma, llamar a un método no compatible no tendrá efectos secundarios y no causará un error en tiempo de ejecución.

Si desea poder saber si un determinado objeto admite un método o no, le sugiero que divida su interfaz en dos con una interfaz super común, y luego escriba verificar el objeto que reciba para determinar qué métodos son compatibles. Esto es probablemente más limpio y más aconsejable que mi primera sugerencia.

interface Frobnicator {} 

interface FooFrobnicator extends Frobnicator { 
    void doFoo(); 
} 

interface BarFrobnicator extends Frobnicator { 
    void doBar(); 
} 

Editar:

Otra forma de hacerlo sería añadir un tipo de retorno booleano a sus métodos, y asegúrese de que sólo se devuelven false si no se admite el método. Por lo tanto:

interface Frobnicator 
{ 
    boolean doFoo(); 
    boolean doBar(); 
} 

class FooFrobnicator implements Frobnicator 
{ 
    public boolean doFoo() { code, code, code; return true; } 
    public boolean doBar() { return false; } 
} 

Answer 3

Veo algunas maneras de manejar esto. Una, que parece ser la táctica general tomada en la API de Java, es simplemente tener la interfaz como se muestra arriba y tener métodos no compatibles aumentar UnsupportedOperationException. Sin embargo, esto tiene la desventaja de no ser a prueba de fallas: el código del cliente no puede decir si doFoo funcionará hasta que intente llamar a doFoo.

Como dijiste, la táctica general es utilizar el patrón de diseño template method. Un excelente ejemplo es el HttpServlet.

Así es como podría lograr lo mismo.

public interface Frobnicator { 
    int doFoo(double v); 
    int doBar(); 
} 

---

public abstract class BaseFrobnicator implements Frobnicator { 
    public int doFoo(double v) { 
     throw new UnsupportedOperationException(); 
    } 
    public int doBar() { 
     throw new UnsupportedOperationException(); 
    } 
} 

---

/** 
* This concrete frobnicator only supports the {@link #doBar()} method. 
*/ 
public class ConcreteFrobnicator extends BaseFrobnicator { 
    public int doBar() { 
     return 42; 
    } 
} 

El cliente acaba de leer los documentos y manejar la UnsupportedOperationException en consecuencia. Como es un RuntimeException, es un caso perfecto para un "error de programador". Es cierto que no es a prueba de fallas (es decir, no es tiempo de compilación), pero es por eso que se le paga como desarrollador. Solo prevenlo o atrapa y maneja.

Answer 4

La solución más obvia es simplemente definir dos interfaces, FooFrobnicator y BarFrobnicator. Esto debería estar bien ya que la clase puede implementar múltiples interfaces.

A continuación, podría proporcionar una interfaz super (marcador) si es necesario.

Answer 5

La solución más sencilla es añadir supports*() métodos,

Si usted piensa que no es un buen estilo, y luego olvidarse de Frobnicator (que le da muy poco, ya que no es una interfaz que puede confiar) y el código directamente contra FooFrobnicator y BarFrobnicator, y si resultan ser implementados por el mismo objeto, bien. Esto también le da la posibilidad de exigir una interfaz específica en el código de cliente:

interface FooFrobnicator { 
    doFoo(); 
} 

interface BarFrobnicator { 
    doBar(); 
} 

public class Client { 
    ... 
    FooFrobnicator fooFrobnicator; 
    public void setFooFrobnicator(FooFrobnicator fooFrobnicator) { 
     this.fooFrobnicator = fooFrobnicator; 
    } 

    BarFrobnicator barFrobnicator; 
    public void setBarFrobnicator(BarFrobnicator barFrobnicator) { 
     this.barFrobnicator = barFrobnicator; 
    } 
    ... 
    public void doSomething() { 
     ... 
     if (fooFrobnicator != null) { ... } 
     ... 
     if (barFrobnicator != null) { ... } 
    } 
} 
... 
public class FrobnicatorImpl implements FooFrobnicator, BarFrobnicator { ... } 
... 
public void doSomething() { 
    ... 
    FrobnicatorImpl impl = new FrobnicatorImpl(); 
    Client client = new Client();   
    client.setFooFrobnicator(impl); 
    client.setBarFrobnicator(impl); 
    ... 
} 

Answer 6

en mi humilde opinión, que está haciendo de esta manera demasiado complicado. Termina con la interfaz. Cree una clase base con los métodos comúnmente utilizados (ni siquiera pueden hacer nada en la clase base si no saben cómo implementarlos allí). A continuación, amplíe la clase base & para implementar/anular los métodos que necesite.