Tránh instanceof trong Java

Có một chuỗi các hoạt động "instanceof" được coi là một "mùi mã". Câu trả lời tiêu chuẩn là "sử dụng tính đa hình". Tôi sẽ làm như thế nào trong trường hợp này?

Có một số lớp con của một lớp cơ sở; không ai trong số họ nằm trong tầm kiểm soát của tôi. Một tình huống tương tự sẽ xảy ra với các lớp Java Integer, Double, BigDecimal, v.v.

if (obj instanceof Integer) {NumberStuff.handle((Integer)obj);}
else if (obj instanceof BigDecimal) {BigDecimalStuff.handle((BigDecimal)obj);}
else if (obj instanceof Double) {DoubleStuff.handle((Double)obj);}

Tôi có quyền kiểm soát NumberStuff, v.v.

Tôi không muốn sử dụng nhiều dòng mã trong đó một vài dòng sẽ làm được. (Đôi khi tôi tạo một HashMap ánh xạ Integer.class đến một phiên bản của IntegerStuff, BigDecimal.class đến một phiên bản BigDecimalStuff, v.v. Nhưng hôm nay tôi muốn một cái gì đó đơn giản hơn.)

Tôi muốn một cái gì đó đơn giản như sau:

public static handle(Integer num) { ... }
public static handle(BigDecimal num) { ... }

Nhưng Java không hoạt động theo cách đó.

Tôi muốn sử dụng các phương thức tĩnh khi định dạng. Những thứ tôi đang định dạng là hỗn hợp, trong đó Thing1 có thể chứa một mảng Thing2 và một Thing2 có thể chứa một mảng Thing1. Tôi đã gặp sự cố khi triển khai các bộ định dạng của mình như sau:

class Thing1Formatter {
  private static Thing2Formatter thing2Formatter = new Thing2Formatter();
  public format(Thing thing) {
      thing2Formatter.format(thing.innerThing2);
  }
}
class Thing2Formatter {
  private static Thing1Formatter thing1Formatter = new Thing1Formatter();
  public format(Thing2 thing) {
      thing1Formatter.format(thing.innerThing1);
  }
}

Vâng, tôi biết HashMap và một đoạn mã khác cũng có thể khắc phục điều đó. Nhưng "instanceof" dường như rất dễ đọc và có thể bảo trì bằng cách so sánh. Có món gì đơn giản mà không nặng mùi?

Ghi chú thêm vào 5/10/2010:

Hóa ra là các lớp con mới có thể sẽ được thêm vào trong tương lai và mã hiện tại của tôi sẽ phải xử lý chúng một cách khéo léo. HashMap trên Class sẽ không hoạt động trong trường hợp đó vì sẽ không tìm thấy Class. Một chuỗi câu lệnh if, bắt đầu bằng câu cụ thể nhất và kết thúc bằng câu chung chung nhất, có lẽ là tốt nhất sau tất cả:

if (obj instanceof SubClass1) {
    // Handle all the methods and properties of SubClass1
} else if (obj instanceof SubClass2) {
    // Handle all the methods and properties of SubClass2
} else if (obj instanceof Interface3) {
    // Unknown class but it implements Interface3
    // so handle those methods and properties
} else if (obj instanceof Interface4) {
    // likewise.  May want to also handle case of
    // object that implements both interfaces.
} else {
    // New (unknown) subclass; do what I can with the base class
}

Bạn có thể quan tâm đến mục này từ blog Amazon của Steve Yegge: "khi đa hình không thành công" . Về cơ bản, anh ấy đang giải quyết những trường hợp như thế này, khi tính đa hình gây ra nhiều rắc rối hơn là nó giải quyết được.

Vấn đề là để sử dụng tính đa hình, bạn phải tạo logic của phần "xử lý" của mỗi lớp 'chuyển đổi' - tức là Số nguyên, v.v. trong trường hợp này. Rõ ràng điều này không thực tế. Đôi khi nó thậm chí không phải là nơi thích hợp để đặt mã về mặt logic. Ông khuyến nghị phương pháp tiếp cận 'ví dụ' để giảm thiểu một số tệ nạn.

Như với tất cả các trường hợp bạn buộc phải viết mã có mùi, hãy giữ cho nó được cài trong một phương pháp (hoặc nhiều nhất là một lớp) để mùi không bị thoát ra ngoài.

Như đã nhấn mạnh trong các nhận xét, mẫu khách truy cập sẽ là một lựa chọn tốt. Nhưng nếu không có sự kiểm soát trực tiếp đối với target / acceptor / visitee, bạn không thể triển khai mô hình đó. Đây là một cách mà mẫu khách truy cập có thể vẫn được sử dụng ở đây mặc dù bạn không có quyền kiểm soát trực tiếp đối với các lớp con bằng cách sử dụng trình bao bọc (lấy Số nguyên làm ví dụ):

public class IntegerWrapper {
    private Integer integer;
    public IntegerWrapper(Integer anInteger){
        integer = anInteger;
    }
    //Access the integer directly such as
    public Integer getInteger() { return integer; }
    //or method passthrough...
    public int intValue() { return integer.intValue(); }
    //then implement your visitor:
    public void accept(NumericVisitor visitor) {
        visitor.visit(this);
    }
}

Tất nhiên, gói một lớp cuối cùng có thể được coi là mùi của riêng nó nhưng có thể nó rất phù hợp với các lớp con của bạn. Cá nhân tôi không nghĩ instanceofrằng có mùi hôi ở đây, đặc biệt là nếu nó được giới hạn trong một phương pháp và tôi rất vui khi sử dụng nó (có thể là theo gợi ý của riêng tôi ở trên). Như bạn nói, nó khá dễ đọc, an toàn và có thể bảo trì. Như mọi khi, hãy giữ nó đơn giản.

Thay vì rất lớn if, bạn có thể đặt các cá thể mà bạn xử lý trong một bản đồ (key: class, value: handler).

Nếu việc tra cứu theo khóa trả về null, hãy gọi một phương thức xử lý đặc biệt để cố gắng tìm một trình xử lý phù hợp (ví dụ bằng cách gọi isInstance()trên mọi khóa trong bản đồ).

Khi tìm thấy một trình xử lý, hãy đăng ký nó theo khóa mới.

Điều này làm cho trường hợp chung nhanh chóng và đơn giản và cho phép bạn xử lý kế thừa.

Bạn có thể sử dụng phản chiếu:

public final class Handler {
  public static void handle(Object o) {
    try {
      Method handler = Handler.class.getMethod("handle", o.getClass());
      handler.invoke(null, o);
    } catch (Exception e) {
      throw new RuntimeException(e);
    }
  }
  public static void handle(Integer num) { /* ... */ }
  public static void handle(BigDecimal num) { /* ... */ }
  // to handle new types, just add more handle methods...
}

Bạn có thể mở rộng ý tưởng để xử lý chung các lớp con và lớp triển khai các giao diện nhất định.

Bạn có thể xem xét mô hình Chuỗi trách nhiệm . Đối với ví dụ đầu tiên của bạn, một cái gì đó như:

public abstract class StuffHandler {
   private StuffHandler next;

   public final boolean handle(Object o) {
      boolean handled = doHandle(o);
      if (handled) { return true; }
      else if (next == null) { return false; }
      else { return next.handle(o); }
   }

   public void setNext(StuffHandler next) { this.next = next; }

   protected abstract boolean doHandle(Object o);
}

public class IntegerHandler extends StuffHandler {
   @Override
   protected boolean doHandle(Object o) {
      if (!o instanceof Integer) {
         return false;
      }
      NumberHandler.handle((Integer) o);
      return true;
   }
}

và sau đó tương tự cho các trình xử lý khác của bạn. Sau đó, đó là trường hợp xâu chuỗi các StuffHandlers lại với nhau theo thứ tự (cụ thể nhất đến cụ thể nhất, với một trình xử lý 'dự phòng' cuối cùng) và mã người gửi của bạn chỉ là firstHandler.handle(o);.

(Một giải pháp thay thế là, thay vì sử dụng chuỗi, chỉ cần có một List<StuffHandler>trong lớp điều phối của bạn và để nó lặp qua danh sách cho đến khi handle()trả về true).

Tôi nghĩ rằng giải pháp tốt nhất là HashMap với Class là khóa và Xử lý là giá trị. Lưu ý rằng giải pháp dựa trên HashMap chạy với độ phức tạp thuật toán không đổi θ (1), trong khi chuỗi có mùi của if-instanceof-else chạy ở độ phức tạp thuật toán tuyến tính O (N), trong đó N là số liên kết trong chuỗi if-instanceof-else (tức là số lượng các lớp khác nhau được xử lý). Vì vậy, hiệu suất của giải pháp dựa trên HashMap cao hơn về mặt tiệm cận N lần so với hiệu suất của giải pháp chuỗi if-instanceof-else. Hãy xem xét rằng bạn cần xử lý các lớp con của lớp Message một cách khác nhau: Message1, Message2, v.v. Dưới đây là đoạn mã để xử lý dựa trên HashMap.

public class YourClass {
    private class Handler {
        public void go(Message message) {
            // the default implementation just notifies that it doesn't handle the message
            System.out.println(
                "Possibly due to a typo, empty handler is set to handle message of type %s : %s",
                message.getClass().toString(), message.toString());
        }
    }
    private Map<Class<? extends Message>, Handler> messageHandling = 
        new HashMap<Class<? extends Message>, Handler>();

    // Constructor of your class is a place to initialize the message handling mechanism    
    public YourClass() {
        messageHandling.put(Message1.class, new Handler() { public void go(Message message) {
            //TODO: IMPLEMENT HERE SOMETHING APPROPRIATE FOR Message1
        } });
        messageHandling.put(Message2.class, new Handler() { public void go(Message message) {
            //TODO: IMPLEMENT HERE SOMETHING APPROPRIATE FOR Message2
        } });
        // etc. for Message3, etc.
    }

    // The method in which you receive a variable of base class Message, but you need to
    //   handle it in accordance to of what derived type that instance is
    public handleMessage(Message message) {
        Handler handler = messageHandling.get(message.getClass());
        if (handler == null) {
            System.out.println(
                "Don't know how to handle message of type %s : %s",
                message.getClass().toString(), message.toString());
        } else {
            handler.go(message);
        }
    }
}

Thông tin thêm về cách sử dụng các biến kiểu Class trong Java: http://docs.oracle.com/javase/tutorial/reflect/class/classNew.html

Chỉ cần đi với instanceof. Tất cả các cách giải quyết có vẻ phức tạp hơn. Đây là một bài đăng trên blog nói về nó: http://www.velocityreviews.com/forums/t302491-instanceof-not-always-bad-the-instanceof-myth.html

Tôi đã giải quyết vấn đề này bằng cách sử dụng reflection(khoảng 15 năm trở lại thời kỳ tiền Generics).

GenericClass object = (GenericClass) Class.forName(specificClassName).newInstance();

Tôi đã định nghĩa một Lớp Chung (lớp Cơ sở trừu tượng). Tôi đã xác định nhiều triển khai cụ thể của lớp cơ sở. Mỗi lớp cụ thể sẽ được tải với tham số className. Tên lớp này được định nghĩa là một phần của cấu hình.

Lớp cơ sở xác định trạng thái chung trên tất cả các lớp cụ thể và các lớp cụ thể sẽ sửa đổi trạng thái bằng cách ghi đè các quy tắc trừu tượng được xác định trong lớp cơ sở.

Vào thời điểm đó, tôi không biết tên của cơ chế này, nó đã được gọi là reflection.

Một số lựa chọn thay thế khác được liệt kê trong bài viết này : Mapvà enumngoài sự phản ánh.