É possível usar o operador instanceof em uma instrução switch?

Eu tenho uma questão de usar switch case para instanceofobjeto:

Por exemplo: meu problema pode ser reproduzido em Java:

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

Como seria implementado usando switch...case?

Esse é um cenário típico em que o polimorfismo de subtipo ajuda. Faça o seguinte

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() } ... }

Em seguida, você pode simplesmente chamar do()no this.

Se você não está livre para mudar A, Be C, você poderia aplicar o padrão do visitante para alcançar o mesmo.

se você absolutamente não puder codificar para uma interface, poderá usar uma enumeração como intermediário:

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;

}

Basta criar um mapa em que a classe seja a chave e a funcionalidade, por exemplo, lambda ou similar, seja o 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());

// é claro, refatorar isso para inicializar apenas uma vez

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

Se você precisar verificar exceções, implemente um FunctionalInterface que lança a exceção e use-o em vez de Runnable.

Apenas no caso de alguém ler:

A melhor solução em java é:

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

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

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

    };

    abstract void doAction (...);
}

Os GRANDES benefícios desse padrão são:

1. Você apenas faz isso (sem interruptores):

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

2. Caso você adicione uma nova ação chamada "d", DEVE aplicar o método doAction (...)

NOTA: Esse padrão é descrito no livro de Joshua Bloch "Effective Java (2nd Edition)"

Você não pode. A switchinstrução pode conter apenas caseinstruções que são constantes de tempo de compilação e avaliadas como um número inteiro (até Java 6 e uma sequência em Java 7).

O que você está procurando é chamado de "correspondência de padrões" na programação funcional.

Consulte também Evitando instanceof em Java

Conforme discutido nas principais respostas, a abordagem tradicional de POO é usar polimorfismo em vez de alternar. Existe até um padrão de refatoração bem documentado para esse truque: Substituir Condicional pelo Polimorfismo . Sempre que busco essa abordagem, também gosto de implementar um objeto Nulo para fornecer o comportamento padrão.

A partir do Java 8, podemos usar lambdas e genéricos para fornecer algo que os programadores funcionais estão familiarizados com: correspondência de padrões. Não é um recurso de linguagem principal, mas a biblioteca Javaslang fornece uma implementação. Exemplo do javadoc :

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

Não é o paradigma mais natural do mundo Java, portanto, use-o com cautela. Embora os métodos genéricos evitem que você tenha que digitar o valor correspondente, estamos perdendo uma maneira padrão de decompor o objeto correspondente, como nas classes de caso do Scala, por exemplo.

Sei que é muito tarde, mas para futuros leitores ...

Cuidado com as abordagens acima, baseadas apenas no nome da classe de A , B , C ...:

A menos que você possa garantir que A , B , C ... (todas as subclasses ou implementadores de Base ) sejam finais , as subclasses de A , B , C ... não serão tratadas.

Embora a abordagem if, elseif, elseif .. seja mais lenta para um grande número de subclasses / implementadores, é mais precisa.

Infelizmente, isso não é possível imediatamente, pois a instrução switch-case espera uma expressão constante. Para superar isso, uma maneira seria usar valores de enumeração com os nomes das classes, por exemplo

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);
 }
}

Com isso é possível usar a instrução switch 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
}

Não, não há como fazer isso. O que você pode querer fazer é considerar o polimorfismo como uma maneira de lidar com esse tipo de problema.

Usar instruções de opção como essa não é a maneira orientada a objetos. Você deve usar o poder do polimorfismo . Basta escrever

this.do()

Tendo configurado anteriormente uma classe base:

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

que é a classe de base para A, Be 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() }
}

Isso funcionará mais rápido e fará sentido caso
- você tenha relativamente "casos"
- o processo seja executado em um contexto sensível ao desempenho

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());
    }
}

Você não pode alternar apenas com os tipos byte, short, char, int, String e enumerados (e as versões de objeto das primitivas, isso também depende da sua versão java. As strings podem ser switcheditadas no java 7)

Eu pessoalmente gosto do seguinte 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");
            });

Saída:

YYyy

O código de exemplo usa Strings, mas você pode usar qualquer tipo de objeto, incluindo Classe. por exemplo.myCase(this.getClass(), (o) -> ...

Precisa do seguinte snippet:

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);
}

O Java agora permite que você alterne da maneira do OP. Eles chamam de Correspondência de Padrões para switch. Atualmente, ele está em rascunho, mas vendo quanto trabalho eles colocaram em switches recentemente, acho que ele será executado. O exemplo dado no JEP é

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();
}  

ou usando sua sintaxe lambda e retornando um 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 qualquer maneira, eles estão fazendo coisas legais com os interruptores.

Se você pode manipular a interface comum, pode adicionar uma enumeração e fazer com que cada classe retorne um valor exclusivo. Você não precisará de instanceof ou um padrão de visitante.

Para mim, a lógica precisava estar escrita na instrução switch, não no objeto em si. Esta foi a minha solução:

ClassA, ClassB, and ClassC implement CommonClass

Interface:

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;
  }
...

Se você estiver no java 7, poderá colocar valores de sequência para a enumeração e o bloco de caixa do comutador ainda funcionará.

Que tal agora ?

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

Eu acho que existem razões para usar uma instrução switch. Se você estiver usando o código gerado pelo xText, talvez. Ou outro tipo de classes geradas pela EMF.

instance.getClass().getName();

retorna uma String do nome de implementação da classe. ou seja: org.eclipse.emf.ecore.util.EcoreUtil

instance.getClass().getSimpleName();

retorna a representação simples, ou seja: EcoreUtil

Se você precisar "alternar" pelo tipo de classe do objeto "this", esta resposta é a melhor https://stackoverflow.com/a/5579385/2078368

Mas se você precisar aplicar "switch" a qualquer outra variável. Eu sugeriria outra solução. Defina a seguinte interface:

public interface ClassTypeInterface {
    public String getType();
}

Implemente essa interface em todas as classes que você deseja "alternar". Exemplo:

public class A extends Something implements ClassTypeInterface {

    public final static String TYPE = "A";

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

Depois disso, você pode usá-lo da seguinte maneira:

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

A única coisa com a qual você deve se preocupar - mantenha os "tipos" exclusivos em todas as classes que implementam o ClassTypeInterface. Não é um grande problema, porque, no caso de qualquer interseção, você recebe um erro em tempo de compilação para a instrução "switch-case".

Aqui está uma maneira funcional de realizá-lo no 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)
        );
    }

Embora não seja possível escrever uma instrução switch, é possível ramificar para um processamento específico para cada tipo especificado. Uma maneira de fazer isso é usar o mecanismo padrão de despacho duplo. Um exemplo em que queremos "alternar" com base no tipo é o mapeador de exceções de Jersey, onde precisamos mapear várias exceções para respostas de erro. Embora neste caso específico exista provavelmente uma maneira melhor (por exemplo, usar um método polimórfico que traduza cada exceção em uma resposta de erro), o uso do mecanismo de despacho duplo ainda é útil e prático.

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);
    }
}

Então, sempre que o "switch" for necessário, você poderá fazer o seguinte:

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";
    }
}

Crie um Enum com nomes de classe.

public enum ClassNameEnum {
    A, B, C
}

Encontre o nome da classe do objeto. Escrever um interruptor de caso sobre o enum.

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 isto ajude.

O Eclipse Modeling Framework tem uma ideia interessante que também considera herança. O conceito básico é definido na interface Switch : a troca é feita invocando o método doSwitch .

O que é realmente interessante é a implementação. Para cada tipo de interesse, um

public T caseXXXX(XXXX object);

O método deve ser implementado (com uma implementação padrão retornando nulo). A implementação doSwitch tentará chamar todos os métodos caseXXX no objeto para toda a sua hierarquia de tipos. Algo nas linhas 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;

A estrutura atual usa um ID inteiro para cada classe, portanto, a lógica é realmente uma opção pura:

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:
    {
      ...
    }
  ...

Você pode ver uma implementação completa do ECoreSwitch para ter uma idéia melhor.

existe uma maneira ainda mais simples de emular uma estrutura de switch que usa instanceof, você faz isso criando um bloco de código no seu método e nomeando-o com um rótulo. Então você usa estruturas if para emular as instruções de caso. Se um caso for verdadeiro, use a interrupção LABEL_NAME para sair da sua estrutura de comutador improvisado.

        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;
            }
        }