Чи можливо використовувати оператор instanceof в операторі комутатора?

У мене виникло питання використання корпусу комутатора для instanceofоб'єкта:

Наприклад: мою проблему можна відтворити на Java:

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

Як це було б реалізовано за допомогою switch...case?

Це типовий сценарій, коли поліморфізм підтипу допомагає. Виконайте наступне

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

Тоді ви можете просто зателефонувати do()по this.

Якщо ви не можете змінювати A, Bі C, ви можете застосувати шаблон відвідувачів, щоб досягти того ж.

якщо ви абсолютно не можете кодувати інтерфейс, ви можете використовувати enum як посередника:

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;

}

Просто створіть Map, де клас є ключовим, а функціональність - лямбда або подібне - значення.

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

// звичайно, рефактор цього, щоб ініціалізувати лише один раз

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

Якщо вам потрібні перевірені винятки, ніж застосувати функціональний інтерфейс, який викидає виняток, і використовувати його замість Runnable.

Про всяк випадок, якщо хтось прочитає його:

НАЙКРАЩЕ рішення у Java:

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

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

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

    };

    abstract void doAction (...);
}

ВЕЛИКІ переваги такого шаблону:

1. Ви просто робите це так, як немає (перемикачів немає):

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

2. У випадку, якщо ви додасте нову дію під назвою "d", ОБОВ'ЯЗКОВО випробувати метод doAction (...)

ПРИМІТКА. Ця модель описана в Блоші Джошуа "Ефективна Java (2-е видання)"

Ви не можете. Оператор switchможе містити лише caseвисловлювання, які є константами часу компіляції та які оцінюються до цілого числа (До Java 6 та рядка в Java 7).

Те, що ви шукаєте, у функціональному програмуванні називається "узгодження зразків".

Див. Також Уникнення instanceof в Java

Як було обговорено у головних відповідях, традиційний підхід ООП полягає у використанні поліморфізму замість комутатора. Для цього трюку є навіть добре задокументована модель рефакторингу: Замінити умовне поліморфізмом . Щоразу, коли я досягаю цього підходу, я люблю також реалізувати об’єкт Null, щоб забезпечити поведінку за замовчуванням.

Починаючи з Java 8, ми можемо використовувати лямбди та дженерики, щоб дати нам щось знайоме з функціональними програмістами: узгодження шаблонів. Це не основна мовна особливість, але бібліотека Javaslang забезпечує одну реалізацію. Приклад з javadoc :

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

Це не найприродніша парадигма в світі Java, тому використовуйте її з обережністю. У той час як загальні методи позбавлять вас від необхідності вводити відповідне значення, нам не вистачає стандартного способу розкласти відповідний об'єкт, як, наприклад, у випадках класів Scala .

Я знаю, що це дуже пізно, але для майбутніх читачів ...

Остерігайтеся вище підходів, які базуються лише на назві класів A , B , C ...:

Якщо ви не зможете гарантувати, що A , B , C ... (всі підкласи або реалізатори Base ) є остаточними, тоді з підкласами A , B , C ... не буде розглядатися.

Хоча підхід if, elseif, elseif .. повільніший для великої кількості підкласів / реалізаторів, він є більш точним.

На жаль, це неможливо вийти з поля, оскільки оператор switch case очікує постійного вираження. Щоб подолати це, одним із способів було б використання значень enum із назвами класів, наприклад

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

З цим можливо використовувати оператор switch таким чином

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
}

Ні, немає ніякого способу зробити це. Однак ви можете захотіти розглянути поліморфізм як спосіб вирішення подібних проблем.

Використання таких операторів перемикання не є об'єктно-орієнтованим способом. Натомість вам слід використовувати силу поліморфізму . Просто напишіть

this.do()

Попередньо встановивши базовий клас:

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

який є базовим класом для A, Bі 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() }
}

Це буде працювати швидше і матиме сенс у випадку
- у вас відносно багато "випадків"
- процес виконується у контексті, залежно від продуктивності

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

Ви не можете перемикатися, що працює лише з байтовими, короткими, char, int, рядковими та переліченими типами (і об'єктними версіями примітивів, це також залежить від вашої версії java. Strings можна switchредагувати в java 7)

Мені особисто подобається такий код 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");
            });

Виведе:

YYyy

У зразковому коді використовуються рядки, але ви можете використовувати будь-який тип об'єкта, включаючи клас. напр.myCase(this.getClass(), (o) -> ...

Потрібен такий фрагмент:

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 дозволяє перемикатися в режимі ОП. Вони називають це узгодження шаблонів для перемикання. Наразі він знаходиться в стадії проекту, але, бачачи, скільки роботи вони нещодавно вводять у вимикачі, я думаю, це пройде. Приклад, наведений у 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();
}  

або використовуючи їх лямбда-синтаксис і повертаючи значення

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

так чи інакше вони робили класні речі з перемикачами.

Якщо ви можете маніпулювати загальним інтерфейсом, ви можете додати перерахунок, і кожен клас поверне унікальне значення. Вам не знадобиться instanceof або шаблон відвідувача.

Для мене логіка повинна бути в написаному в операторі комутатора, а не в самому об'єкті. Це було моє рішення:

ClassA, ClassB, and ClassC implement CommonClass

Інтерфейс:

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

Імпл .:

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

Якщо ви знаходитесь на java 7, ви можете поставити рядкові значення для enum, і блок корпусу комутатора все одно буде працювати.

Як щодо цього?

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

Я думаю, що є причини використовувати оператор switch. Якщо ви, можливо, використовуєте код, створений xText. Або інший клас, створений ЕМП класами.

instance.getClass().getName();

повертає рядок Ім'я впровадження класу. тобто: org.eclipse.emf.ecore.util.EcoreUtil

instance.getClass().getSimpleName();

повертає просту репресію, тобто: EcoreUtil

Якщо вам потрібно "переключити" через тип класу "цього" об'єкта, ця відповідь найкраща https://stackoverflow.com/a/5579385/2078368

Але якщо вам потрібно застосувати "перемикач" на будь-яку іншу змінну. Я б запропонував інше рішення. Визначте наступний інтерфейс:

public interface ClassTypeInterface {
    public String getType();
}

Реалізуйте цей інтерфейс у кожному класі, який ви хочете "переключити". Приклад:

public class A extends Something implements ClassTypeInterface {

    public final static String TYPE = "A";

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

Після цього ви можете використовувати його наступним чином:

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

Єдине, про що вам слід подбати - зберегти унікальні "типи" для всіх класів, що реалізують ClassTypeInterface. Це не велика проблема, тому що в разі будь-якого перехрестя ви отримуєте помилку часу компіляції для оператора "switch-case".

Ось функціональний спосіб її виконання в Java 8 за допомогою 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)
        );
    }

Хоча неможливо написати оператор перемикання, можливо розгалуження на конкретну обробку для кожного заданого типу. Один із способів зробити це - використовувати стандартний механізм подвійної диспетчеризації. Прикладом, коли ми хочемо «переключитися» на основі типу, є перетворювач Jersey Exception, де нам потрібно відобразити безліч винятків із відповідей на помилки. Хоча для цього конкретного випадку існує, мабуть, кращий спосіб (тобто використання поліморфного методу, який переводить кожен виняток у відповідь на помилку), використання подвійного механізму відправки все ще корисне і практичне.

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

Тоді де колись потрібен «перемикач», ви можете зробити це так:

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

Створіть Enum з іменами класів.

public enum ClassNameEnum {
    A, B, C
}

Знайдіть назву класу об’єкта. Напишіть справу перемикача над перерахунком.

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

Сподіваюсь, це допомагає.

Рамка моделювання Eclipse має цікаву ідею, яка також враховує спадщину. Основна концепція визначена в інтерфейсі Switch : перемикання здійснюється шляхом виклику методу doSwitch .

Що насправді цікаво - це реалізація. Для кожного типу відсотків:

public T caseXXXX(XXXX object);

метод повинен бути реалізований (з типовою реалізацією, що повертає нуль). Реалізація doSwitch спробує викликати всі об'єкти caseXXX на об'єкт для всієї його ієрархії типів. Щось у рядках:

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;

Фактичний фреймворк використовує цілий ідентифікатор для кожного класу, тому логіка насправді є чистим перемикачем:

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

Ви можете ознайомитись з повною реалізацією ECoreSwitch, щоб отримати кращу ідею.

є ще простіший спосіб емуляції структури комутатора, який використовує instanceof, ви робите це, створюючи блок коду у своєму методі та називаючи його міткою. Тоді ви використовуєте if структури для імітації випадок справи. Якщо виправданий випадок, ви використовуєте перерву LABEL_NAME, щоб вийти зі своєї структури імпровізованих комутаторів.

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