Có thể sử dụng toán tử instanceof trong câu lệnh switch không?

Tôi có một câu hỏi về việc sử dụng trường hợp chuyển đổi cho instanceofđối tượng:

Ví dụ: vấn đề của tôi có thể được sao chép trong Java:

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

Làm thế nào nó sẽ được thực hiện bằng cách sử dụng switch...case?

Đây là một kịch bản điển hình trong đó đa hình phụ giúp. Làm như sau

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

Sau đó, bạn có thể chỉ cần gọi do()vào this.

Nếu bạn không được tự do thay đổi A, Bvà C, bạn có thể áp dụng mô hình khách truy cập để đạt được điều tương tự.

nếu bạn hoàn toàn không thể mã hóa giao diện, thì bạn có thể sử dụng enum làm trung gian:

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;

}

Chỉ cần tạo một Bản đồ trong đó lớp là khóa và chức năng, tức là lambda hoặc tương tự, là giá trị.

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

// tất nhiên, cấu trúc lại cái này để chỉ khởi tạo một lần

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

Nếu bạn cần kiểm tra Ngoại lệ hơn là triển khai FunctionalInterface, ném Ngoại lệ và sử dụng ngoại lệ đó thay vì Runnable.

Chỉ trong trường hợp nếu ai đó sẽ đọc nó:

Giải pháp TỐT NHẤT trong java là:

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

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

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

    };

    abstract void doAction (...);
}

Những lợi ích TUYỆT VỜI của mẫu đó là:

1. Bạn chỉ cần làm như thế (KHÔNG có công tắc nào cả):

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

2. Trong trường hợp nếu bạn thêm Hành động mới gọi là "d", bạn PHẢI thực hiện phương thức doAction (...)

LƯU Ý: Mẫu này được mô tả trong Joshua's Bloch "Java hiệu quả (Phiên bản 2)"

Bạn không thể. Câu switchlệnh chỉ có thể chứa các casecâu lệnh là các hằng số thời gian biên dịch và đánh giá thành một số nguyên (Lên đến Java 6 và một chuỗi trong Java 7).

Những gì bạn đang tìm kiếm được gọi là "khớp mẫu" trong lập trình chức năng.

Xem thêm Tránh thể hiện trong Java

Như đã thảo luận trong các câu trả lời hàng đầu, phương pháp OOP truyền thống là sử dụng đa hình thay vì chuyển đổi. Thậm chí còn có một mô hình tái cấu trúc được ghi chép tốt cho thủ thuật này: Thay thế điều kiện bằng đa hình . Bất cứ khi nào tôi tiếp cận phương pháp này, tôi cũng muốn triển khai một đối tượng Null để cung cấp hành vi mặc định.

Bắt đầu với Java 8, chúng ta có thể sử dụng lambdas và generic để cung cấp cho chúng ta một thứ mà các lập trình viên chức năng rất quen thuộc: khớp mẫu. Đây không phải là một tính năng ngôn ngữ cốt lõi nhưng thư viện Javaslang cung cấp một triển khai. Ví dụ từ javadoc :

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

Đây không phải là mô hình tự nhiên nhất trong thế giới Java, vì vậy hãy thận trọng khi sử dụng nó. Mặc dù các phương thức chung sẽ giúp bạn không phải đánh máy giá trị khớp, nhưng chúng ta đang thiếu một cách tiêu chuẩn để phân tách đối tượng phù hợp như với các lớp trường hợp của Scala chẳng hạn.

Tôi biết điều này là rất muộn nhưng đối với độc giả tương lai ...

Cảnh giác với các cách tiếp cận ở trên chỉ dựa trên tên của lớp A , B , C ...:

Trừ khi bạn có thể đảm bảo rằng A , B , C ... (tất cả các lớp con hoặc người triển khai Base ) là cuối cùng thì các lớp con của A , B , C ... sẽ không bị xử lý.

Mặc dù cách tiếp cận if, otherif, otherif .. chậm hơn đối với số lượng lớn các lớp con / người thực hiện, nhưng nó chính xác hơn.

Thật không may, không thể ra khỏi hộp vì câu lệnh tình huống chuyển đổi mong đợi một biểu thức không đổi. Để khắc phục điều này, một cách sẽ là sử dụng các giá trị enum với các tên lớp, vd

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

Với điều đó là có thể sử dụng câu lệnh chuyển đổi như thế này

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
}

Không, không có cách nào để làm điều này. Tuy nhiên, những gì bạn có thể muốn làm là xem xét Đa hình như một cách để xử lý các loại vấn đề này.

Sử dụng các câu lệnh chuyển đổi như thế này không phải là cách hướng đối tượng. Thay vào đó bạn nên sử dụng sức mạnh của đa hình . Đơn giản chỉ cần viết

this.do()

Trước đây đã thiết lập một lớp cơ sở:

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

đó là lớp cơ sở cho A, Bvà 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() }
}

Điều này sẽ hoạt động nhanh hơn và có ý nghĩa trong trường hợp
- bạn có tương đối nhiều 'trường hợp'
- quá trình được thực hiện trong bối cảnh nhạy cảm về hiệu suất

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

Bạn không thể chuyển đổi chỉ hoạt động với các kiểu byte, short, char, int, String và liệt kê (và các phiên bản đối tượng của nguyên thủy, nó cũng phụ thuộc vào phiên bản java của bạn, Chuỗi có thể được chỉnh sửa switchtrong java 7)

Cá nhân tôi thích mã Java 1.8 sau:

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

Sẽ xuất:

YYyy

Mã mẫu sử dụng Chuỗi nhưng bạn có thể sử dụng bất kỳ loại đối tượng nào, kể cả Class. ví dụ.myCase(this.getClass(), (o) -> ...

Cần đoạn trích sau:

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 bây giờ cho phép bạn chuyển đổi theo cách của OP. Họ gọi nó là khớp mẫu cho chuyển đổi. Nó hiện đang được soạn thảo nhưng nhìn thấy bao nhiêu công việc họ đã đưa vào thiết bị chuyển mạch gần đây tôi nghĩ rằng nó sẽ đi qua. Ví dụ được đưa ra trong JEP là

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

hoặc sử dụng cú pháp lambda của họ và trả về một giá trị

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

dù bằng cách nào họ đã làm những thứ tuyệt vời với công tắc.

Nếu bạn có thể thao tác giao diện chung, bạn có thể thêm vào một enum và mỗi lớp trả về một giá trị duy nhất. Bạn sẽ không cần thể hiện hoặc mẫu khách truy cập.

Đối với tôi, logic cần có trong văn bản trong câu lệnh switch chứ không phải chính đối tượng. Đây là giải pháp của tôi:

ClassA, ClassB, and ClassC implement CommonClass

Giao diện:

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

Nếu bạn đang dùng java 7, bạn có thể đặt các giá trị chuỗi cho enum và khối trường hợp chuyển đổi vẫn sẽ hoạt động.

Còn cái này thì sao ?

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

Tôi nghĩ rằng có những lý do để sử dụng một tuyên bố chuyển đổi. Nếu bạn đang sử dụng xText tạo Mã có lẽ. Hoặc một loại khác của các lớp tạo EMF.

instance.getClass().getName();

trả về một chuỗi của tên thực hiện lớp. tức là: org.eclipse.emf.ecore.util.EcoreUtil

instance.getClass().getSimpleName();

trả về sự hồi phục đơn giản, tức là: EcoreUtil

Nếu bạn cần "chuyển đổi" thông qua loại lớp của đối tượng "này", câu trả lời này là https://stackoverflow.com/a/5579385/2078368 tốt nhất

Nhưng nếu bạn cần áp dụng "chuyển đổi" cho bất kỳ biến nào khác. Tôi sẽ đề nghị một giải pháp khác. Xác định giao diện sau:

public interface ClassTypeInterface {
    public String getType();
}

Thực hiện giao diện này trong mỗi lớp bạn muốn "chuyển đổi". Thí dụ:

public class A extends Something implements ClassTypeInterface {

    public final static String TYPE = "A";

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

Sau đó, bạn có thể sử dụng nó theo cách sau:

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

Điều duy nhất bạn nên quan tâm - giữ "các loại" duy nhất trên tất cả các lớp triển khai ClassTypeInterface. Đó không phải là một vấn đề lớn, bởi vì trong bất kỳ giao lộ nào, bạn sẽ nhận được lỗi thời gian biên dịch cho câu lệnh "trường hợp chuyển đổi".

Đây là một cách chức năng để thực hiện nó trong Java 8 bằng cách sử dụng 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)
        );
    }

Mặc dù không thể viết một câu lệnh chuyển đổi, nhưng có thể phân nhánh để xử lý cụ thể cho từng loại đã cho. Một cách để làm điều này là sử dụng cơ chế điều phối kép tiêu chuẩn. Một ví dụ mà chúng tôi muốn "chuyển đổi" dựa trên loại là trình ánh xạ Jersey Exception nơi chúng tôi cần ánh xạ vô số ngoại lệ cho các phản hồi lỗi. Mặc dù đối với trường hợp cụ thể này, có lẽ có một cách tốt hơn (nghĩa là sử dụng phương pháp đa hình để dịch từng ngoại lệ thành phản hồi lỗi), sử dụng cơ chế điều phối kép vẫn hữu ích và thiết thực.

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

Sau đó, bất cứ khi nào cần "chuyển đổi", bạn có thể làm như sau:

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

Tạo một Enum với tên Class.

public enum ClassNameEnum {
    A, B, C
}

Tìm tên lớp của đối tượng. Viết một trường hợp chuyển đổi trên 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;
        }
    }
}

Hi vọng điêu nay co ich.

Khung mô hình hóa Eclipse có một ý tưởng thú vị cũng xem xét tính kế thừa. Khái niệm cơ bản được định nghĩa trong giao diện Switch : chuyển đổi được thực hiện bằng cách gọi phương thức doSwitch .

Điều thực sự thú vị là việc thực hiện. Đối với mỗi loại sở thích, một

public T caseXXXX(XXXX object);

phương thức phải được thực hiện (với việc thực hiện mặc định trả về null). Việc triển khai doSwitch sẽ cố gắng gọi al các phương thức caseXXX trên đối tượng cho tất cả hệ thống phân cấp kiểu của nó. Một cái gì đó trong dòng:

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;

Khung thực tế sử dụng một id số nguyên cho mỗi lớp, vì vậy logic thực sự là một chuyển đổi thuần túy:

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

Bạn có thể xem xét một triển khai hoàn chỉnh của ECoreSwitch để có được ý tưởng tốt hơn.

thậm chí còn có một cách đơn giản hơn để mô phỏng cấu trúc chuyển đổi sử dụng thể hiện, bạn thực hiện điều này bằng cách tạo một khối mã trong phương thức của bạn và đặt tên cho nó bằng nhãn. Sau đó, bạn sử dụng if cấu trúc để mô phỏng các báo cáo trường hợp. Nếu một trường hợp là đúng thì bạn sử dụng break LABEL_NAME để thoát khỏi cấu trúc chuyển đổi tạm thời của bạn.

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