¿Es posible usar el operador instanceof en una instrucción switch?

Tengo una pregunta sobre el uso de mayúsculas y minúsculas para el instanceofobjeto:

Por ejemplo: mi problema se puede reproducir en Java:

if(this instanceof A)
    doA();
else if(this instanceof B)
    doB();
else if(this instanceof C)
    doC():

¿Cómo se implementaría usando switch...case?

Este es un escenario típico donde ayuda el subtipo de polimorfismo. Haz lo siguiente

interface I {
  void do();
}

class A implements I { void do() { doA() } ... }
class B implements I { void do() { doB() } ... }
class C implements I { void do() { doC() } ... }

A continuación, puede llamar do()a this.

Si no está libre de cambiar A, By C, se podría aplicar el patrón de visitante para lograr el mismo.

si absolutamente no puede codificar a una interfaz, entonces podría usar una enumeración como intermediario:

public A() {

    CLAZZ z = CLAZZ.valueOf(this.getClass().getSimpleName());
    switch (z) {
    case A:
        doA();
        break;
    case B:
        doB();
        break;
    case C:
        doC();
        break;
    }
}


enum CLAZZ {
    A,B,C;

}

Simplemente cree un mapa donde la clase sea la clave y la funcionalidad, es decir, lambda o similar, sea el valor.

Map<Class,Runnable> doByClass = new HashMap<>();
doByClass.put(Foo.class, () -> doAClosure(this));
doByClass.put(Bar.class, this::doBMethod);
doByClass.put(Baz.class, new MyCRunnable());

// por supuesto, refactorice esto para inicializar solo una vez

doByClass.get(getClass()).run();

Si necesita marcar Excepciones que implementar una interfaz funcional que arroje la excepción y la use en lugar de Runnable.

Por si acaso alguien lo leerá:

La MEJOR solución en java es:

public enum Action { 
    a{
        void doAction(...){
            // some code
        }

    }, 
    b{
        void doAction(...){
            // some code
        }

    }, 
    c{
        void doAction(...){
            // some code
        }

    };

    abstract void doAction (...);
}

Los GRANDES beneficios de dicho patrón son:

1. Simplemente hazlo como (NO hay interruptores):

   void someFunction ( Action action ) {
       action.doAction(...);   
   }

2. En caso de que si agrega una nueva Acción llamada "d", DEBE implementar el método doAction (...)

NOTA: Este patrón se describe en el Bloch de Joshua "Java efectivo (2ª edición)"

No puedes La switchdeclaración solo puede contener casedeclaraciones que son constantes de tiempo de compilación y que evalúan a un entero (hasta Java 6 y una cadena en Java 7).

Lo que está buscando se llama "coincidencia de patrones" en la programación funcional.

Consulte también Evitar instanceof en Java

Como se discutió en las respuestas principales, el enfoque OOP tradicional es usar polimorfismo en lugar de cambiar. Incluso hay un patrón de refactorización bien documentado para este truco: Reemplazar condicional por polimorfismo . Cada vez que busco este enfoque, me gusta implementar también un objeto nulo para proporcionar el comportamiento predeterminado.

Comenzando con Java 8, podemos usar lambdas y genéricos para darnos algo con lo que los programadores funcionales están muy familiarizados: coincidencia de patrones. No es una característica central del lenguaje, pero la biblioteca Javaslang proporciona una implementación. Ejemplo del javadoc :

Match.ofType(Number.class)
    .caze((Integer i) -> i)
    .caze((String s) -> new BigDecimal(s))
    .orElse(() -> -1)
    .apply(1.0d); // result: -1

No es el paradigma más natural en el mundo de Java, así que úselo con precaución. Si bien los métodos genéricos le evitarán tener que escribir el valor coincidente, nos falta una forma estándar de descomponer el objeto coincidente como, por ejemplo, con las clases de caso de Scala .

Sé que es muy tarde, pero para futuros lectores ...

Tenga cuidado con los enfoques anteriores que se basan solo en el nombre de la clase de A , B , C ...:

A menos que pueda garantizar que A , B , C ... (todas las subclases o implementadores de Base ) sean finales , las subclases de A , B , C ... no se tratarán.

Aunque el enfoque if, elseif, elseif .. es más lento para un gran número de subclases / implementadores, es más preciso.

Desafortunadamente, no es posible fuera de la caja ya que la declaración de cambio de caso espera una expresión constante. Para superar esto, una forma sería usar valores de enumeración con los nombres de clase, por ejemplo

public enum MyEnum {
   A(A.class.getName()), 
   B(B.class.getName()),
   C(C.class.getName());

private String refClassname;
private static final Map<String, MyEnum> ENUM_MAP;

MyEnum (String refClassname) {
    this.refClassname = refClassname;
}

static {
    Map<String, MyEnum> map = new ConcurrentHashMap<String, MyEnum>();
    for (MyEnum instance : MyEnum.values()) {
        map.put(instance.refClassname, instance);
    }
    ENUM_MAP = Collections.unmodifiableMap(map);
}

public static MyEnum get(String name) {
    return ENUM_MAP.get(name);
 }
}

Con eso es posible usar la declaración de cambio como esta

MyEnum type = MyEnum.get(clazz.getName());
switch (type) {
case A:
    ... // it's A class
case B:
    ... // it's B class
case C:
    ... // it's C class
}

No, no hay forma de hacer esto. Sin embargo, lo que quizás desee hacer es considerar el polimorfismo como una forma de manejar este tipo de problemas.

El uso de declaraciones de cambio como esta no es la forma orientada a objetos. En su lugar, debes usar el poder del polimorfismo . Simplemente escribe

this.do()

Habiendo configurado previamente una clase base:

abstract class Base {
   abstract void do();
   ...
}

que es la clase base para A, By C:

class A extends Base {
    void do() { this.doA() }
}

class B extends Base {
    void do() { this.doB() }
}

class C extends Base {
    void do() { this.doC() }
}

Esto funcionará más rápido y tendrá sentido en caso de
que tenga muchos casos
, el proceso se ejecuta en un contexto sensible al rendimiento

public <T> T process(Object model) {
    switch (model.getClass().getSimpleName()) {
        case "Trade":
            return processTrade();
        case "InsuranceTransaction":
            return processInsuranceTransaction();
        case "CashTransaction":
            return processCashTransaction();
        case "CardTransaction":
            return processCardTransaction();
        case "TransferTransaction":
            return processTransferTransaction();
        case "ClientAccount":
            return processAccount();
        ...
        default:
            throw new IllegalArgumentException(model.getClass().getSimpleName());
    }
}

No puede un switch solo funciona con los tipos byte, short, char, int, String y enumerados (y las versiones de objeto de las primitivas, también depende de su versión de Java, las cadenas se pueden switcheditar en Java 7)

Personalmente me gusta el siguiente código Java 1.8:

    mySwitch("YY")
            .myCase("AA", (o) -> {
                System.out.println(o+"aa");
            })
            .myCase("BB", (o) -> {
                System.out.println(o+"bb");
            })
            .myCase("YY", (o) -> {
                System.out.println(o+"yy");
            })
            .myCase("ZZ", (o) -> {
                System.out.println(o+"zz");
            });

Saldrá:

YYyy

El código de muestra usa cadenas, pero puede usar cualquier tipo de objeto, incluida la clase. p.ej.myCase(this.getClass(), (o) -> ...

Necesita el siguiente fragmento:

public Case mySwitch(Object reference) {
    return new Case(reference);
}

public class Case {

    private Object reference;

    public Case(Object reference) {
        this.reference = reference;
    }

    public Case myCase(Object b, OnMatchDo task) {
        if (reference.equals(b)) {
            task.task(reference);
        }
        return this;
    }
}

public interface OnMatchDo {

    public void task(Object o);
}

Java ahora le permite cambiar a la manera del OP. Lo llaman Pattern Matching para cambiar. Actualmente está en borrador, pero al ver cuánto trabajo han estado poniendo en los interruptores recientemente, creo que pasará. El ejemplo dado en el JEP es

String formatted;
switch (obj) {
    case Integer i: formatted = String.format("int %d", i); break;
    case Byte b:    formatted = String.format("byte %d", b); break;
    case Long l:    formatted = String.format("long %d", l); break;
    case Double d:  formatted = String.format("double %f", d); break;
    case String s:  formatted = String.format("String %s", s); break
    default:        formatted = obj.toString();
}  

o usando su sintaxis lambda y devolviendo un valor

String formatted = 
    switch (obj) {
        case Integer i -> String.format("int %d", i)
        case Byte b    -> String.format("byte %d", b);
        case Long l    -> String.format("long %d", l); 
        case Double d  -> String.format("double %f", d); 
        case String s  -> String.format("String %s", s); 
        default        -> obj.toString();
    };

De cualquier manera, han estado haciendo cosas geniales con los interruptores.

Si puede manipular la interfaz común, puede agregar una enumeración y hacer que cada clase devuelva un valor único. No necesitará instanceof o un patrón de visitante.

Para mí, la lógica tenía que estar escrita en la declaración de cambio, no el objeto en sí. Esta fue mi solución:

ClassA, ClassB, and ClassC implement CommonClass

Interfaz:

public interface CommonClass {
   MyEnum getEnumType();
}

Enum:

public enum MyEnum {
  ClassA(0), ClassB(1), ClassC(2);

  private int value;

  private MyEnum(final int value) {
    this.value = value;
  }

  public int getValue() {
    return value;
  }

Impl:

...
  switch(obj.getEnumType())
  {
    case MyEnum.ClassA:
      ClassA classA = (ClassA) obj;
    break;

    case MyEnum.ClassB:
      ClassB classB = (ClassB) obj;
    break;

    case MyEnum.ClassC:
      ClassC classC = (ClassC) obj;
    break;
  }
...

Si está en Java 7, puede poner valores de cadena para la enumeración y el bloque de mayúsculas y minúsculas seguirá funcionando.

Qué tal esto ?

switch (this.name) 
{
  case "A":
    doA();
    break;
  case "B":
    doB();
    break;
  case "C":
    doC();
    break;
  default:
    console.log('Undefined instance');
}

Creo que hay razones para usar una declaración de cambio. Si está utilizando el código generado por xText, tal vez. O otro tipo de clases generadas por EMF.

instance.getClass().getName();

devuelve una cadena del nombre de implementación de clase. es decir: org.eclipse.emf.ecore.util.EcoreUtil

instance.getClass().getSimpleName();

devuelve la representación simple, es decir: EcoreUtil

Si necesita "cambiar" a través del tipo de clase de "este" objeto, esta respuesta es la mejor https://stackoverflow.com/a/5579385/2078368

Pero si necesita aplicar "cambiar" a cualquier otra variable. Sugeriría otra solución. Defina la siguiente interfaz:

public interface ClassTypeInterface {
    public String getType();
}

Implemente esta interfaz en cada clase que desee "cambiar". Ejemplo:

public class A extends Something implements ClassTypeInterface {

    public final static String TYPE = "A";

    @Override
    public String getType() {
        return TYPE;
    }
}

Después de eso, puede usarlo de la siguiente manera:

switch (var.getType()) {
    case A.TYPE: {
        break;
    }
    case B.TYPE: {
        break;
    }
    ...
}

Lo único que debería importarle es mantener los "tipos" únicos en todas las clases que implementan ClassTypeInterface. No es un gran problema, porque en caso de cualquier intersección, recibirá un error en tiempo de compilación para la instrucción "switch-case".

Aquí hay una forma funcional de lograrlo en Java 8 usando http://www.vavr.io/

import static io.vavr.API.*;
import static io.vavr.Predicates.instanceOf;
public Throwable liftRootCause(final Throwable throwable) {
        return Match(throwable).of(
                Case($(instanceOf(CompletionException.class)), Throwable::getCause),
                Case($(instanceOf(ExecutionException.class)), Throwable::getCause),
                Case($(), th -> th)
        );
    }

Si bien no es posible escribir una declaración de cambio, es posible ramificarse a un procesamiento específico para cada tipo dado. Una forma de hacerlo es utilizar un mecanismo estándar de despacho doble. Un ejemplo en el que queremos "cambiar" según el tipo es el mapeador de excepciones de Jersey, donde necesitamos mapear multitud de excepciones a las respuestas de error. Si bien para este caso específico probablemente haya una mejor manera (es decir, usar un método polimórfico que traduzca cada excepción a una respuesta de error), el uso del mecanismo de doble despacho sigue siendo útil y práctico.

interface Processable {
    <R> R process(final Processor<R> processor);
}

interface Processor<R> {
    R process(final A a);
    R process(final B b);
    R process(final C c);
    // for each type of Processable
    ...
}

class A implements Processable {
    // other class logic here

    <R> R process(final Processor<R> processor){
        return processor.process(this);
    }
}

class B implements Processable {
    // other class logic here

    <R> R process(final Processor<R> processor){
        return processor.process(this);
    }
}

class C implements Processable {
    // other class logic here

    <R> R process(final Processor<R> processor){
        return processor.process(this);
    }
}

Entonces, siempre que se necesite el "interruptor", puede hacerlo de la siguiente manera:

public class LogProcessor implements Processor<String> {
    private static final Logger log = Logger.for(LogProcessor.class);

    public void logIt(final Processable base) {
        log.info("Logging for type {}", process(base));
    }

    // Processor methods, these are basically the effective "case" statements
    String process(final A a) {
        return "Stringifying A";
    }

    String process(final B b) {
        return "Stringifying B";
    }

    String process(final C c) {
        return "Stringifying C";
    }
}

Crear una enumeración con nombres de clase.

public enum ClassNameEnum {
    A, B, C
}

Encuentra el nombre de la clase del objeto. Escriba un caso de cambio sobre la enumeración.

private void switchByClassType(Object obj) {

        ClassNameEnum className = ClassNameEnum.valueOf(obj.getClass().getSimpleName());

        switch (className) {
            case A:
                doA();
                break;
            case B:
                doB();
                break;
            case C:
                doC();
                break;
        }
    }
}

Espero que esto ayude.

El Marco de modelado de Eclipse tiene una idea interesante que también considera la herencia. El concepto básico se define en la interfaz Switch : el cambio se realiza invocando el método doSwitch .

Lo que es realmente interesante es la implementación. Para cada tipo de interés, un

public T caseXXXX(XXXX object);

El método debe implementarse (con una implementación predeterminada que devuelve nulo). La implementación de doSwitch intentará llamar a todos los métodos caseXXX en el objeto para toda su jerarquía de tipos. Algo en las líneas de:

BaseType baseType = (BaseType)object;
T result = caseBaseType(eAttribute);
if (result == null) result = caseSuperType1(baseType);
if (result == null) result = caseSuperType2(baseType);
if (result == null) result = caseSuperType3(baseType);
if (result == null) result = caseSuperType4(baseType);
if (result == null) result = defaultCase(object);
return result;

El marco real utiliza una identificación entera para cada clase, por lo que la lógica es en realidad un interruptor puro:

public T doSwitch(Object object) {
    return doSwitch(object.class(), eObject);
}

protected T doSwitch(Class clazz, Object object) {
    return doSwitch(getClassifierID(clazz), object);
}

protected T doSwitch(int classifierID, Object theObject) {
    switch (classifierID) {
    case MyClasses.BASETYPE:
    {
      BaseType baseType = (BaseType)object;
      ...
      return result;
    }
    case MyClasses.TYPE1:
    {
      ...
    }
  ...

Puede ver una implementación completa de ECoreSwitch para tener una mejor idea.

hay una forma aún más simple de emular una estructura de conmutador que usa instanceof, lo haces creando un bloque de código en tu método y nombrándolo con una etiqueta. Luego usas estructuras if para emular las declaraciones de casos. Si un caso es verdadero, entonces usa la ruptura LABEL_NAME para salir de su estructura de interruptor improvisada.

        DEFINE_TYPE:
        {
            if (a instanceof x){
                //do something
                break DEFINE_TYPE;
            }
            if (a instanceof y){
               //do something
                break DEFINE_TYPE;
            }
            if (a instanceof z){
                // do something
                break DEFINE_TYPE;
            }
        }