Czy można użyć operatora instanceof w instrukcji switch?

Mam pytanie o użycie skrzynki rozdzielczej dla instanceofobiektu:

Na przykład: mój problem można odtworzyć w Javie:

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

Jak można to zaimplementować za pomocą switch...case?

Jest to typowy scenariusz, w którym pomaga polimorfizm podtypu. Wykonaj następujące czynności

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

Następnie można po prostu zadzwonić do()na this.

Jeśli nie masz możliwości zmiany A, Bi Cmożesz zastosować wzór odwiedzin, aby osiągnąć to samo.

jeśli absolutnie nie możesz kodować do interfejsu, możesz użyć wyliczenia jako pośrednika:

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;

}

Wystarczy utworzyć mapę, w której klasa jest kluczem, a funkcjonalność, tj. Lambda lub podobna, jest wartością.

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

// oczywiście zrefaktoryzuj to, aby zainicjować tylko raz

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

Jeśli potrzebujesz zaznaczonych wyjątków, zaimplementuj interfejs FunctionalInterface, który zgłasza wyjątek i użyj go zamiast Runnable.

Na wszelki wypadek, jeśli ktoś to przeczyta:

Najlepszym rozwiązaniem w java jest:

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

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

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

    };

    abstract void doAction (...);
}

WIELKIE zalety takiego wzoru to:

1. Po prostu robisz to tak (żadnych przełączników):

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

2. W przypadku dodania nowej akcji o nazwie „d” MUSISZ zastosować metodę doAction (...)

UWAGA: Ten wzór jest opisany w Blos Joshua „Effective Java (2nd Edition)”

Nie możesz switchZestawienie może zawierać tylko casedeklaracje, które są kompilacji stałe czasowe i które ocenia się całkowitą (do Java 6 i ciąg w Javie 7).

To, czego szukasz, nazywa się „dopasowaniem wzorców” w programowaniu funkcjonalnym.

Zobacz także Unikanie instancji w Javie

Jak omówiono w najważniejszych odpowiedziach, tradycyjne podejście OOP polega na użyciu polimorfizmu zamiast zamiany. Istnieje nawet dobrze udokumentowany wzorzec refaktoryzacji dla tej sztuczki: Zamień warunkowy na polimorfizm . Ilekroć sięgam po to podejście, lubię również implementować obiekt Null, aby zapewnić domyślne zachowanie.

Począwszy od Java 8, możemy używać lambd i generics, aby dać nam coś, co programiści są bardzo obeznani z: dopasowaniem wzorców. To nie jest podstawowa funkcja języka, ale biblioteka JavaScript zapewnia jedną implementację. Przykład z javadoc :

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

To nie jest najbardziej naturalny paradygmat w świecie Java, więc używaj go ostrożnie. Chociaż ogólne metody pozwolą ci uniknąć konieczności typowania wartości dopasowanej, brakuje nam standardowego sposobu dekompozycji dopasowanego obiektu, jak na przykład w przypadku klas przypadków Scali .

Wiem, że jest bardzo późno, ale dla przyszłych czytelników ...

Uważaj na powyższe podejścia, które opierają się tylko na nazwie klasy A , B , C ...:

O ile nie możesz zagwarantować, że A , B , C ... (wszystkie podklasy lub realizatorzy Base ) są ostateczne, podklasy A , B , C ... nie będą rozpatrywane.

Chociaż podejście if, elseif, elseif .. jest wolniejsze dla dużej liczby podklas / implementatorów, jest bardziej dokładne.

Niestety nie jest to możliwe od razu po wyjęciu z pudełka, ponieważ instrukcja case-switch oczekuje stałego wyrażenia. Aby temu zaradzić, jednym ze sposobów byłoby użycie wartości wyliczeniowych z nazwami klas, np

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

Dzięki temu możliwe jest użycie instrukcji switch w ten sposób

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
}

Nie, nie ma na to sposobu. Możesz jednak rozważyć polimorfizm jako sposób na poradzenie sobie z tego rodzaju problemami.

Używanie instrukcji switch w ten sposób nie jest zorientowane obiektowo. Zamiast tego powinieneś użyć mocy polimorfizmu . Po prostu napisz

this.do()

Po wcześniejszym skonfigurowaniu klasy podstawowej:

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

który jest klasą bazową dla A, Bi 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() }
}

Będzie to działało szybciej i sprawi, że w przypadku
- gdy masz stosunkowo wiele „przypadków”
- proces jest wykonywany w kontekście wrażliwym na wydajność

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

Nie możesz przełącznika działać tylko z typami bajtów, krótkich, char, int, String i wyliczonymi (i obiektowymi wersjami prymitywów, zależy to również od wersji java, ciągi można switchedytować w java 7)

Osobiście podoba mi się następujący kod 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");
            });

Wyjdzie:

YYyy

W przykładowym kodzie zastosowano ciągi, ale można użyć dowolnego typu obiektu, w tym klasy. na przykład.myCase(this.getClass(), (o) -> ...

Potrzebuje następującego fragmentu kodu:

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 pozwala teraz przełączać się w sposób OP. Nazywają to dopasowywanie wzorców dla przełącznika. Obecnie jest w fazie Draft, ale biorąc pod uwagę, ile pracy włożono ostatnio w przełączniki, myślę, że to przejdzie. Przykład podany w JEP to

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

lub używając ich składni lambda i zwracając wartość

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

tak czy inaczej robili fajne rzeczy z przełącznikami.

Jeśli możesz manipulować wspólnym interfejsem, możesz dodać wartość dodaną w wyliczeniu, a każda klasa zwróci unikalną wartość. Nie potrzebujesz instancji ani wzorca odwiedzającego.

Dla mnie logika musiała być zapisana w instrukcji switch, a nie sam obiekt. To było moje rozwiązanie:

ClassA, ClassB, and ClassC implement CommonClass

Berło:

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

Jeśli korzystasz z java 7, możesz wstawić wartości ciągu dla wyliczenia, a blok skrzynki przełączników będzie nadal działał.

Co powiesz na to ?

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

Myślę, że istnieją powody, aby używać instrukcji switch. Jeśli używasz kodu wygenerowanego xText, być może. Lub inny rodzaj klas generowanych przez EMF.

instance.getClass().getName();

zwraca ciąg nazwy implementacji klasy. tj .: org.eclipse.emf.ecore.util.EcoreUtil

instance.getClass().getSimpleName();

zwraca prostą reprezentację, tj .: EcoreUtil

Jeśli potrzebujesz „przełączyć” typ klasy „tego” obiektu, ta odpowiedź jest najlepsza https://stackoverflow.com/a/5579385/2078368

Ale jeśli musisz zastosować „zmień” na dowolną inną zmienną. Sugerowałbym inne rozwiązanie. Zdefiniuj następujący interfejs:

public interface ClassTypeInterface {
    public String getType();
}

Zaimplementuj ten interfejs w każdej klasie, którą chcesz „przełączyć”. Przykład:

public class A extends Something implements ClassTypeInterface {

    public final static String TYPE = "A";

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

Następnie możesz go użyć w następujący sposób:

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

Jedyną rzeczą, na którą powinieneś zwrócić uwagę - zachować unikalność „typów” we wszystkich klasach implementujących interfejs ClassTypeInterface. Nie jest to duży problem, ponieważ w przypadku jakiegokolwiek skrzyżowania pojawia się błąd czasu kompilacji dla instrukcji „case-case”.

Oto funkcjonalny sposób na osiągnięcie tego w Javie 8 przy użyciu 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)
        );
    }

Chociaż nie jest możliwe napisanie instrukcji switch, możliwe jest rozgałęzienie do określonego przetwarzania dla każdego danego typu. Jednym ze sposobów jest użycie standardowego mechanizmu podwójnej wysyłki. Przykładem, w którym chcemy „przełączyć” w zależności od typu, jest program mapujący wyjątek Jersey, w którym musimy zmapować wiele wyjątków od odpowiedzi na błędy. Chociaż w tym konkretnym przypadku istnieje prawdopodobnie lepszy sposób (tj. Zastosowanie metody polimorficznej, która tłumaczy każdy wyjątek na odpowiedź na błąd), użycie mechanizmu podwójnej wysyłki jest nadal przydatne i praktyczne.

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

Tam, gdzie kiedykolwiek potrzebny jest „przełącznik”, możesz to zrobić w następujący sposób:

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

Utwórz Enum z nazwami klas.

public enum ClassNameEnum {
    A, B, C
}

Znajdź nazwę klasy obiektu. Napisz skrzynkę przełączającą nad wyliczeniem.

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

Mam nadzieję że to pomoże.

Środowisko modelowania Eclipse ma interesujący pomysł, który uwzględnia również dziedziczenie. Podstawowa koncepcja została zdefiniowana w interfejsie Switch : przełączanie odbywa się poprzez wywołanie metody doSwitch .

Naprawdę ciekawe jest wdrożenie. Dla każdego rodzaju zainteresowania:

public T caseXXXX(XXXX object);

Metoda musi zostać zaimplementowana (z domyślną implementacją zwracającą wartość null). DoSwitch realizacja będzie próbował zadzwonić AL caseXXX metod na obiekcie dla całej jego rodzaj hierarchii. Coś w linii:

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;

Rzeczywista struktura używa identyfikatora liczb całkowitych dla każdej klasy, więc logika jest w rzeczywistości czystym przełącznikiem:

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

Możesz spojrzeć na pełną implementację ECoreSwitch, aby uzyskać lepszy pomysł.

istnieje jeszcze prostszy sposób emulacji struktury przełącznika, który korzysta z instanceof. Robisz to, tworząc blok kodu w metodzie i nazywając go etykietą. Następnie używasz struktur if do emulacji instrukcji case. Jeśli przypadek jest prawdziwy, użyj przerwy LABEL_NAME, aby wyjść ze struktury prowizorycznego przełącznika.

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