Tengo una clase base, Base. Tiene dos subclases Sub1y Sub2. Cada subclase tiene algunos métodos adicionales. Por ejemplo, Sub1tiene Sandwich makeASandwich(Ingredients... ingredients)y Sub2tiene boolean contactAliens(Frequency onFrequency).

Dado que estos métodos toman parámetros diferentes y hacen cosas completamente diferentes, son completamente incompatibles, y no puedo usar el polimorfismo para resolver este problema.

Baseproporciona la mayor parte de la funcionalidad, y tengo una gran colección de Baseobjetos. Sin embargo, todos los Baseobjetos son a Sub1o a Sub2, y a veces necesito saber cuáles son.

Parece una mala idea hacer lo siguiente:

for (Base base : bases) {
    if (base instanceof Sub1) {
        ((Sub1) base).makeASandwich(getRandomIngredients());
        // ... etc.
    } else { // must be Sub2
        ((Sub2) base).contactAliens(getFrequency());
        // ... etc.
    }
}

Así que se me ocurrió una estrategia para evitar esto sin lanzar. Baseahora tiene estos métodos:

boolean isSub1();
Sub1 asSub1();
Sub2 asSub2();

Y, por supuesto, Sub1implementa estos métodos como

boolean isSub1() { return true; }
Sub1 asSub1();   { return this; }
Sub2 asSub2();   { throw new IllegalStateException(); }

Y los Sub2implementa de la manera opuesta.

Lamentablemente, ahora Sub1y Sub2tienen estos métodos en su propia API. Entonces puedo hacer esto, por ejemplo, en Sub1.

/** no need to use this if object is known to be Sub1 */
@Deprecated
boolean isSub1() { return true; }

/** no need to use this if object is known to be Sub1 */
@Deprecated
Sub1 asSub1();   { return this; }

/** no need to use this if object is known to be Sub1 */
@Deprecated
Sub2 asSub2();   { throw new IllegalStateException(); }

De esta manera, si se sabe que el objeto es solo a Base, estos métodos no están en desuso y se pueden usar para "lanzarse" a un tipo diferente para que yo pueda invocar los métodos de la subclase. Esto me parece elegante de alguna manera, pero por otro lado, estoy abusando de las anotaciones obsoletas como una forma de "eliminar" métodos de una clase.

Dado que una Sub1instancia realmente es una Base, tiene sentido usar la herencia en lugar de la encapsulación. ¿Lo que estoy haciendo bien? ¿Hay una mejor manera de resolver este problema?

No siempre tiene sentido agregar funciones a la clase base, como se sugiere en algunas de las otras respuestas. Agregar demasiadas funciones de casos especiales puede dar como resultado la unión de componentes que de otro modo no estarían relacionados.

Por ejemplo, podría tener una Animalclase, con Caty Dogcomponentes. Si quiero ser capaz de imprimir, o los mostrará en la interfaz gráfica de usuario que puede ser excesiva para que añada renderToGUI(...)y sendToPrinter(...)de la clase base.

El enfoque que está utilizando, utilizando verificaciones de tipo y modelos, es frágil, pero al menos mantiene las preocupaciones separadas.

Sin embargo, si te encuentras haciendo este tipo de verificaciones / lanzamientos con frecuencia, entonces una opción es implementar el patrón de visitante / doble despacho para ello. Se parece a esto:

public abstract class Base {
  ...
  abstract void visit( BaseVisitor visitor );
}

public class Sub1 extends Base {
  ...
  void visit(BaseVisitor visitor) { visitor.onSub1(this); }
}

public class Sub2 extends Base {
  ...
  void visit(BaseVisitor visitor) { visitor.onSub2(this); }
}

public interface BaseVisitor {
   void onSub1(Sub1 that);
   void onSub2(Sub2 that);
}

Ahora tu código se convierte

public class ActOnBase implements BaseVisitor {
    void onSub1(Sub1 that) {
       that.makeASandwich(getRandomIngredients())
    }

    void onSub2(Sub2 that) {
       that.contactAliens(getFrequency());
    }
}

BaseVisitor visitor = new ActOnBase();
for (Base base : bases) {
    base.visit(visitor);
}

El principal beneficio es que si agrega una subclase, obtendrá errores de compilación en lugar de casos que faltan silenciosamente. La nueva clase de visitante también se convierte en un buen objetivo para incorporar funciones. Por ejemplo, podría tener sentido para moverse getRandomIngredients()en ActOnBase.

También puede extraer la lógica de bucle: por ejemplo, el fragmento anterior podría convertirse

BaseVisitor.applyToArray(bases, new ActOnBase() );

Un poco más de masajes y el uso de lambdas y transmisión de Java 8 le permitirán llegar a

bases.stream()
     .forEach( BaseVisitor.forEach(
       Sub1 that -> that.makeASandwich(getRandomIngredients()),
       Sub2 that -> that.contactAliens(getFrequency())
     ));

Qué IMO tiene el aspecto más prolijo y conciso posible.

Aquí hay un ejemplo más completo de Java 8:

public static abstract class Base {
    abstract void visit( BaseVisitor visitor );
}

public static class Sub1 extends Base {
    void visit(BaseVisitor visitor) { visitor.onSub1(this); }

    void makeASandwich() {
        System.out.println("making a sandwich");
    }
}

public static class Sub2 extends Base {
    void visit(BaseVisitor visitor) { visitor.onSub2(this); }

    void contactAliens() {
        System.out.println("contacting aliens");
    }
}

public interface BaseVisitor {
    void onSub1(Sub1 that);
    void onSub2(Sub2 that);

    static Consumer<Base> forEach(Consumer<Sub1> sub1, Consumer<Sub2> sub2) {

        return base -> {
            BaseVisitor baseVisitor = new BaseVisitor() {

                @Override
                public void onSub1(Sub1 that) {
                    sub1.accept(that);
                }

                @Override
                public void onSub2(Sub2 that) {
                    sub2.accept(that);
                }
            };
            base.visit(baseVisitor);
        };
    }
}

Collection<Base> bases = Arrays.asList(new Sub1(), new Sub2());

bases.stream()
     .forEach(BaseVisitor.forEach(
             Sub1::makeASandwich,
             Sub2::contactAliens));

Desde mi perspectiva: tu diseño está equivocado .

Traducido al lenguaje natural, estás diciendo lo siguiente:

Dado que tenemos animals, hay catsy fish. animalstener propiedades, que son comunes a catsy fish. Pero eso no es suficiente: hay algunas propiedades que hacen diferentes cata partir fish, por lo tanto, que necesita subclase.

Ahora tiene el problema, que olvidó modelar el movimiento . Bueno. Eso es relativamente fácil:

for(Animal a : animals){
   if (a instanceof Fish) swim();
   if (a instanceof Cat) walk();
}

Pero ese es un diseño incorrecto. La forma correcta sería:

for(Animal a : animals){
    animal.move()
}

Donde movese compartiría el comportamiento implementado de manera diferente por cada animal.

Dado que estos métodos toman parámetros diferentes y hacen cosas completamente diferentes, son completamente incompatibles, y no puedo usar el polimorfismo para resolver este problema.

Esto significa: su diseño está roto.

Mi recomendación: refactor Base, Sub1y Sub2.

Es un poco difícil imaginar una circunstancia en la que tienes un grupo de cosas y quieres que hagan un sándwich o contacten a extraterrestres. En la mayoría de los casos en los que encuentre este tipo de conversión, operará con un tipo; por ejemplo, en clang, filtrará un conjunto de nodos para las declaraciones donde getAsFunction devuelve no nulo, en lugar de hacer algo diferente para cada nodo en la lista.

Puede ser que necesite realizar una secuencia de acción y en realidad no es relevante que los objetos que realizan la acción estén relacionados.

Entonces, en lugar de una lista de Base, trabaje en la lista de acciones

for (RandomAction action : actions)
   action.act(context);

dónde

interface RandomAction {
    void act(Context context);
} 

interface Context {
    Ingredients getRandomIngredients();
    double getFrequency();
}

Puede, si corresponde, hacer que Base implemente un método para devolver la acción, o cualquier otro medio que necesite para seleccionar la acción de las instancias en su lista base (ya que dice que no puede usar el polimorfismo, entonces, presumiblemente, la acción a tomar no es una función de la clase, sino alguna otra propiedad de las bases; de lo contrario, solo le daría a Base el método act (Context)

¿Qué tal si sus subclases implementan una o más interfaces que definen lo que pueden hacer? Algo como esto:

interface SandwichCook
{
    public void makeASandwich(String[] ingredients);
}

interface AlienRadioSignalAwarable
{
    public void contactAliens(int frequency);

}

Entonces tus clases se verán así:

class Sub1 extends Base implements SandwichCook
{
    public void makeASandwich(String[] ingredients)
    {
        //some code here
    }
}

class Sub2 extends Base implements AlienRadioSignalAwarable
{
    public void contactAliens(int frequency)
    {
        //some code here
    }
}

Y su bucle for se convertirá en:

for (Base base : bases) {
    if (base instanceof SandwichCook) {
        base.makeASandwich(getRandomIngredients());
    } else if (base instanceof AlienRadioSignalAwarable) {
        base.contactAliens(getFrequency());
    }
}

Dos ventajas principales de este enfoque:

• sin casting involucrado
• puede hacer que cada subclase implemente tantas interfaces como desee, lo que proporciona cierta flexibilidad para futuros cambios.

PD: Perdón por los nombres de las interfaces, no se me ocurrió nada más genial en ese momento en particular: D.

El enfoque puede ser una buena en los casos en que casi cualquier tipo dentro de una familia , ya sea directamente utilizable como una implementación de alguna de las interfaces que cumple algún criterio o se puede utilizar para crear una implementación de la interfaz. Los tipos de colección integrados en mi humilde opinión se habrían beneficiado de este patrón, pero como no lo hacen, por ejemplo, inventaré una interfaz de colección BunchOfThings<T>.

Algunas implementaciones de BunchOfThingsson mutables; algunos no lo son. En muchos casos, un objeto que Fred podría querer contener algo que pueda usar como BunchOfThingsy sepa que nada más que Fred podrá modificarlo. Este requisito puede cumplirse de dos maneras:

1. Fred sabe que tiene las únicas referencias a eso BunchOfThings, y no existe ninguna referencia externa a eso en BunchOfThingssus partes internas en ningún lugar del universo. Si nadie más tiene una referencia a BunchOfThingssus componentes internos, nadie más podrá modificarlo, por lo que se cumplirá la restricción.

2. Ni el BunchOfThings, ni ninguno de sus componentes internos a los que existen referencias externas, pueden modificarse por cualquier medio. Si absolutamente nadie puede modificar a BunchOfThings, entonces la restricción será satisfecha.

Una forma de satisfacer la restricción sería copiar incondicionalmente cualquier objeto recibido (procesando recursivamente cualquier componente anidado). Otra sería probar si un objeto recibido promete inmutabilidad y, si no, hacer una copia del mismo, y hacer lo mismo con cualquier componente anidado. Una alternativa, que es más limpia que la segunda y más rápida que la primera, es ofrecer un AsImmutablemétodo que le pida a un objeto que haga una copia inmutable de sí mismo (utilizando AsImmutablecualquier componente anidado que lo admita).

También se pueden proporcionar métodos relacionados asDetached(para usar cuando el código recibe un objeto y no sabe si querrá mutarlo, en cuyo caso un objeto mutable debe reemplazarse por un nuevo objeto mutable, pero un objeto inmutable puede mantenerse como está), asMutable(en los casos en que un objeto sabe que contendrá un objeto devuelto anteriormente asDetached, es decir, una referencia no compartida a un objeto mutable o una referencia que se puede compartir a un objeto mutable), y asNewMutable(en los casos en que el código recibe un exterior referencia y sabe que va a querer mutar una copia de los datos allí; si los datos entrantes son mutables, no hay razón para comenzar haciendo una copia inmutable que se usará inmediatamente para crear una copia mutable y luego se abandonará).

Tenga en cuenta que, si bien los asXXmétodos pueden devolver tipos ligeramente diferentes, su función real es garantizar que los objetos devueltos satisfagan las necesidades del programa.

Ignorando la cuestión de si tiene un buen diseño o no, y suponiendo que sea bueno o al menos aceptable, me gustaría considerar las capacidades de las subclases, no el tipo.

Por lo tanto, ya sea:

Transfiera algún conocimiento de la existencia de sándwiches y extraterrestres a la clase base, aunque sepa que algunas instancias de la clase base no pueden hacerlo. Impleméntelo en la clase base para generar excepciones y cambie el código a:

if (base.canMakeASandwich()) {
    base.makeASandwich(getRandomIngredients());
    // ... etc.
} else { // can't make sandwiches, must be able to contact aliens
    base.contactAliens(getFrequency());
    // ... etc.
}

Luego, una o ambas subclases anulan canMakeASandwich(), y solo una implementa cada una de makeASandwich()y contactAliens().

Use interfaces, no subclases concretas, para detectar qué capacidades tiene un tipo. Deje la clase base sola y cambie el código a:

if (base instanceof SandwichMaker) {
    ((SandwichMaker)base).makeASandwich(getRandomIngredients());
    // ... etc.
} else { // can't make sandwiches, must be able to contact aliens
    ((AlienContacter)base).contactAliens(getFrequency());
    // ... etc.
}

o posiblemente (y siéntase libre de ignorar esta opción si no se adapta a su estilo, o para cualquier estilo Java que considere razonable):

try {
    ((SandwichMaker)base).makeASandwich(getRandomIngredients());
} catch (ClassCastException e) {
    ((AlienContacter)base).contactAliens(getFrequency());
}

Personalmente, generalmente no me gusta el último estilo de capturar una excepción medio esperada, debido al riesgo de detectar inapropiadamente una ClassCastExceptionsalida de getRandomIngredientso makeASandwich, pero YMMV.

Aquí tenemos un caso interesante de una clase base que se reduce a sus propias clases derivadas. Sabemos muy bien que esto normalmente es malo, pero si queremos decir que encontramos una buena razón, veamos y veamos cuáles pueden ser las limitaciones:

1. Podemos cubrir todos los casos en la clase base.
2. Ninguna clase derivada extranjera tendría que agregar un nuevo caso, nunca.
3. Podemos vivir con la política para la cual llamar a estar bajo el control de la clase base.
4. Pero sabemos por nuestra ciencia que la política de qué hacer en una clase derivada para un método que no está en la clase base es la de la clase derivada y no la clase base.

Si 4 entonces tenemos: 5. La política de la clase derivada siempre está bajo el mismo control político que la política de la clase base.

2 y 5 implican directamente que podemos enumerar todas las clases derivadas, lo que significa que no se supone que haya ninguna clase derivada externa.

Pero aquí está la cosa. Si son todos suyos, puede reemplazar el if con una abstracción que es una llamada a un método virtual (incluso si es una tontería) y deshacerse del if y self-cast. Por lo tanto, no lo hagas. Un mejor diseño está disponible.

Coloque un método abstracto en la clase base que haga una cosa en Sub1 y la otra en Sub2, y llame a ese método abstracto en sus bucles mixtos.

class Sub1 : Base {
    @Override void doAThing() {
        this.makeASandwich(getRandomIngredients());
    }
}

class Sub2 : Base {
    @Override void doAThing() {
        this.contactAliens(getFrequency());
    }
}

for (Base base : bases) {
    base.doAThing();
}

Tenga en cuenta que esto puede requerir otros cambios dependiendo de cómo se definan getRandomIngredients y getFrequency. Pero, sinceramente, dentro de la clase que contacta a extraterrestres es probablemente un mejor lugar para definir getFrequency de todos modos.

Por cierto, sus métodos asSub1 y asSub2 son definitivamente una mala práctica. Si vas a hacer esto, hazlo lanzando. No hay nada que estos métodos te den que el casting no tenga.

Puede que haya empujado tanto makeASandwichy contactAliensen la clase base y luego ponerlas en práctica con implementaciones ficticias. Dado que los tipos / argumentos de retorno no pueden resolverse en una clase base común.

class Sub1 extends Base{
    Sandwich makeASandwich(Ingredients i){
        //Normal implementation
    }
    boolean contactAliens(Frequency onFrequency){
        return false;
    }
 }
class Sub2 extends Base{
    Sandwich makeASandwich(Ingredients i){
        return null;
    }
    boolean contactAliens(Frequency onFrequency){
       // normal implementation
    }
 }

Hay desventajas obvias para este tipo de cosas, como lo que eso significa para el contrato del método y lo que puede y no puede inferir sobre el contexto del resultado. No se puede pensar, ya que no pude hacer un sándwich, los ingredientes se agotaron en el intento, etc.

Lo que estás haciendo es perfectamente legítimo. No presten atención a los detractores que simplemente reiteran el dogma porque lo leen en algunos libros. Dogma no tiene lugar en la ingeniería.

He empleado el mismo mecanismo un par de veces, y puedo decir con confianza que el tiempo de ejecución de Java también podría haber hecho lo mismo en al menos un lugar en el que puedo pensar, mejorando así el rendimiento, la usabilidad y la legibilidad del código que lo usa

Tomemos, por ejemplo java.lang.reflect.Member, cuál es la base de java.lang.reflect.Fieldy java.lang.reflect.Method. (La jerarquía real es un poco más complicada que eso, pero eso es irrelevante). Los campos y los métodos son animales muy diferentes: uno tiene un valor que puede obtener o establecer, mientras que el otro no tiene tal cosa, pero puede invocarse con una serie de parámetros y puede devolver un valor. Por lo tanto, los campos y los métodos son miembros, pero las cosas que puede hacer con ellos son tan diferentes entre sí como hacer sándwiches frente a contactar con extraterrestres.

Ahora, cuando escribimos código que usa la reflexión, a menudo tenemos un Memberen nuestras manos, y sabemos que es un a Methodo un Field(o, raramente, algo más) y, sin embargo, tenemos que hacer todo lo tedioso instanceofpara descubrir con precisión qué es y luego tenemos que lanzarlo para obtener una referencia adecuada. (Y esto no solo es tedioso, sino que tampoco funciona muy bien). La Methodclase podría haber implementado muy fácilmente el patrón que está describiendo, facilitando así la vida de miles de programadores.

Por supuesto, esta técnica solo es viable en jerarquías pequeñas y bien definidas de clases estrechamente acopladas de las que usted tiene (y siempre tendrá) control de nivel de origen: no desea hacer tal cosa si su jerarquía de clases es Es probable que sea extendido por personas que no están en libertad de refactorizar la clase base.

Así es como lo que he hecho difiere de lo que has hecho:

• La clase base proporciona una implementación predeterminada para toda la asDerivedClass()familia de métodos, haciendo que cada uno de ellos regrese null.

• Cada clase derivada solo anula uno de los asDerivedClass()métodos, regresando en thislugar de null. No anula nada del resto, ni quiere saber nada sobre ellos. Por lo tanto, no IllegalStateExceptionse arrojan s.

• La clase base también proporciona finalimplementaciones para toda la isDerivedClass()familia de métodos, codificados de la siguiente manera: De return asDerivedClass() != null; esta manera, se minimiza el número de métodos que deben ser anulados por las clases derivadas.

• No he estado usando @Deprecatedeste mecanismo porque no lo pensé. Ahora que me diste la idea, la pondré en práctica, ¡gracias!

C # tiene un mecanismo relacionado incorporado mediante el uso de la aspalabra clave. En C # puede decir DerivedClass derivedInstance = baseInstance as DerivedClassy obtendrá una referencia a DerivedClasssi su baseInstancepertenecía a esa clase o nullno. Esto (teóricamente) funciona mejor que lo isseguido por la conversión ( ises la palabra clave de C # mejor nombrada para instanceof), pero el mecanismo personalizado para el que hemos estado trabajando a mano funciona aún mejor: el par de instanceofoperaciones de lanzamiento y lanzamiento de Java también ya que el asoperador de C # no funciona tan rápido como la llamada de método virtual único de nuestro enfoque personalizado.

Por la presente, propongo que esta técnica debe declararse como un patrón y que se debe encontrar un buen nombre para ello.

Gee, gracias por los votos negativos!

Un resumen de la controversia, para salvarlo de la molestia de leer los comentarios:

La objeción de la gente parece ser que el diseño original era incorrecto, lo que significa que nunca debería haber clases muy diferentes que se derivan de una clase base común, o que incluso si lo hace, el código que utiliza dicha jerarquía nunca debería estar en la posición de tener una referencia base y la necesidad de descubrir la clase derivada. Por lo tanto, dicen, el mecanismo de autoelaboración propuesto por esta pregunta y por mi respuesta, que mejora el uso del diseño original, nunca debería haber sido necesario en primer lugar. (Realmente no dicen nada sobre el mecanismo de auto-fundición en sí, solo se quejan de la naturaleza de los diseños a los que se debe aplicar el mecanismo).

Sin embargo, en el ejemplo anterior que han ya demostrado que los creadores de la ejecución de Java, en efecto, elegir el diseño precisamente tal para el java.lang.reflect.Member, Field, Methodjerarquía, y en los comentarios a continuación que también muestran que los creadores de la C # tiempo de ejecución llegado independientemente a una equivalente diseño para el System.Reflection.MemberInfo, FieldInfo, MethodInfojerarquía. Por lo tanto, estos son dos escenarios diferentes del mundo real que se encuentran justo debajo de la nariz de todos y que tienen soluciones demostrablemente viables utilizando precisamente tales diseños.

A eso se reducen todos los siguientes comentarios. El mecanismo de auto-fundición apenas se menciona.