reservada - Java: regresando la subclase en la firma del método superclase

super en java

Question

Estoy trabajando en un problema donde hay varias implementaciones de Foo , acompañadas por varias de FooBuilder . Si bien Foo comparte varias variables comunes que deben configurarse, también tienen variables distintas que requieren sus respectivos FooBuilder para implementar alguna funcionalidad específica. Para ser concisos, me gustaría que los FooBuilder de FooBuilder usen el encadenamiento de métodos, como:

public abstract class FooBuilder {
  ...

  public FooBuilder setA(int A) {
    this.A = A;
    return this;
  }

  ...
}

y

public class FooImplBuilder extends FooBuilder{
  ...
  public FooImplBuilder setB(int B) {
    this.B = B;
    return this;
  }
  public FooImplBuilder setC(int C) {
    this.C = C;
    return this;
  }
  ...
}

Y así sucesivamente, con varias implementaciones diferentes de FooBuilder . Esto técnicamente hace todo lo que quiero, sin embargo, este enfoque es sensible al orden de las llamadas de métodos cuando se realiza el encadenamiento de métodos. Lo siguiente tiene errores de compilación de método indefinido:

someFoo.setA(a).setB(b)...

Requerir que el desarrollador piense en el orden de las llamadas de método en la cadena. Para evitar esto, me gustaría que los FooBuilder de FooBuilder devuelvan la subclase de implementación real. Sin embargo, no estoy seguro de cómo hacer esto. ¿Cuál es el mejor enfoque?

Answer 1

Esta es una buena pregunta y un problema real.

La forma más fácil de lidiar con esto en Java probablemente involucre el uso de genéricos, como se menciona en la respuesta de Jochen.

Hay una buena discusión del problema y una solución razonable en esta entrada de blog sobre el uso de la herencia con interfaces getThis() , que combina los genéricos con la definición de un método getThis() en las subclases del constructor para resolver el problema de devolver siempre un generador del correcto clase.

Answer 2

Habiendo encontrado esta excelente respuesta , ahora la estoy compartiendo.

public class SuperClass<I extends SuperClass>
{
    @SuppressWarnings( "unchecked" ) // If you''re annoyed by Lint.
    public I doStuff( Object withThings )
    {
        // Do stuff with things.
        return (I)this ; // Will always cast to the subclass. Causes the Lint warning.
    }
}

public class ImplementationOne
extends SuperClass<ImplementationOne>
{} // doStuff() will return an instance of ImplementationOne

public class ImplementationTwo
extends SuperClass<ImplementationTwo>
{} // doStuff() will return an instance of ImplementationTwo

Answer 3

Los genéricos podrían ser el camino a seguir aquí.

Si declara setA () algo como esto (pseudo-código)

<T> T setA(int a)

el compilador debería ser capaz de averiguar los tipos reales, y si no lo hace, puede dar pistas en el código como

obj.<RealFoo>setA(42)