Tính ổn định của khách truy cập so với tính linh hoạt của thể hiện

Tôi đang làm việc trên một ứng dụng GUI tạo tệp cấu hình. Tôi có một hệ thống phân cấp lớp cho mô hình cấu hình và tôi sử dụng một cây đối tượng của hệ thống phân cấp đó trong một số bối cảnh khác nhau. Hiện tại, tôi sử dụng mẫu Khách truy cập để tránh gây ô nhiễm các lớp mô hình của mình bằng mã cụ thể theo ngữ cảnh.

interface IConfigurationElement {
    void acceptVisitor(IConfigurationElementVisitor visitor);
}

Trong phiên bản trước, tôi đã sử dụng chuỗi instanceofđiều kiện thay vì Khách truy cập. So sánh hai cách tiếp cận tôi thấy các giao dịch sau.

Khách thăm quan

• Nó là dễ dàng hơn và an toàn hơn để thêm mới IConfigurationElement. Chỉ cần thêm một khai báo mới IConfigurationElementVisitorvà trình biên dịch sẽ tạo ra lỗi cho tất cả các cài đặt của khách truy cập. Với instanceofcác chuỗi bạn phải nhớ tất cả các vị trí bạn phải mở rộng với thành phần cấu hình mới. Về cơ bản instanceofvi phạm nguyên tắc DRY vì nó sao chép logic ở một số nơi.
• Mẫu khách truy cập hiệu quả hơn một chuỗi các instanceofđiều kiện

ví dụ

• Ưu điểm lớn của instanceofnó là tính linh hoạt của nó. Ví dụ, instanceof cho phép tôi xác định các giải pháp đặc biệt cho các tập hợp con khác nhau của các IConfigurationElementtriển khai cần được xử lý tương tự trong một số trường hợp. Ngược lại, Khách truy cập buộc tôi phải thực hiện một phương thức cho mỗi lớp triển khai mỗi lần.

Có một giải pháp chung cho loại vấn đề này? Tôi có thể điều chỉnh Khách truy cập bằng cách nào đó không, vì vậy tôi có thể cung cấp giải pháp chung cho một số trường hợp?

Bạn có thể sử dụng khách truy cập với instanceOf

giao diện:

interface Visitable {
  void accept(Object visitor);
}
interface AVisitor {
  void visitA(A a);
}
interface BVisitor {
  void visitB(B b);
}
interface CVisitor {
  void visitB(C c);
}

Lượt truy cập:

class C implements Visitable {
  public void accept(Object visitor) {
    if (visitor instanceof CVisitor) {
      ((BVisitor)vistor).visitC(this);
    }
  }
}

class B implements Visitable {
  public void accept(Object visitor) {
    if (visitor instanceof BVisitor) {
      ((BVisitor)vistor).visitB(this);
    }
  }
}

class A extends B implements Visitable {
  public void accept(Object visitor) {
    super.accept(visitor);
    if (visitor instanceof AVisitor) {
      ((AVisitor)vistor).visitA(this);
    }
  }
}

Khách:

class PrintBs implements BVisitor {
  public void visitB(B b) {
    system.out.println(b);
  }
}

class PrintAs implements AVisitor {
  public void visitA(A a) {
    system.out.println(a);
  }
}

class PrintCs implements CVisitor {
  public void visitC(C c) {
    system.out.println(c);
  }
}
class PrintAsAndCs implements CVisitor, AVisitor{
  public void visitA(A a) {
    system.out.println(a);
  }
  public void visitC(C c) {
    system.out.println(c);
  }
}

mỗi lớp chỉ biết về các giao diện liên quan của nó, vì vậy, việc thêm vistors mới hoặc truy cập yêu cầu thay đổi mọi thứ trong danh mục đó (khách truy cập / có thể truy cập) (đối với khách truy cập, nó không yêu cầu thay đổi bất cứ điều gì, vì có thể truy cập, nó yêu cầu tạo giao diện khách truy cập mới, nhưng một lần nữa, không thay đổi các đối tượng hiện có).

Theo cách này, không có chuỗi thử nghiệm thể hiện và khách truy cập cho tập hợp con thậm chí không cần biết về các loại bên ngoài tập hợp con này.

Câu hỏi là phải làm gì với tình huống A mở rộng B (và B cũng có thể truy cập được), trong trường hợp đó, bạn có thể thêm super.accept (khách truy cập) vào chấp nhận (do đó sẽ là chuỗi ngắn của instanceof-s, nhưng onlu như miễn là hệ thống phân cấp sâu, và nó không quá sâu đối với vấn đề, abd bạn không cần phải viết toàn bộ bằng tay).

Vâng, vâng, bạn có thể. Nắm bắt sự tương đồng của nhiều yếu tố cấu hình bằng cách gán vai trò cho chúng. Bạn có thể kết thúc bằng cá thể, nhưng không phải theo cách vi phạm nguyên tắc DRY, mà là cách xoay quanh việc gõ tĩnh của Java.

class ConfigurationElementA implements IConfigurationElement, ICommittable {
}

class ConfigurationElementB implements IConfigurationElement, IVerifiable {
}

class Visitor {
    void accept(IConfigurationElement element) {
        if (element instanceof ICommittable) {
            // ...
        }

        // Note: not a chain of instanceofs.

        if (element instanceof IVerifiable) {
            // ...
        }
    }
}

Nói cách khác, bạn cho phép khách truy cập chấp nhận các yếu tố cấu hình một cách khái quát và hành động theo các nhóm thực hiện thông qua các vai trò. Lưu ý rằng bạn có thể đi cụ thể như bạn cần bằng cách mô hình hóa các yếu tố cấu hình phù hợp.

Bạn có thể nhận ra ở đây mẫu RoleInterface của Martin Fowler .

Tôi có thể nghĩ về một số giải pháp tiềm năng:

1. tạo một phương thức riêng trong Visitortriển khai và có nhiều visitphương thức trong Visitorthực hiện gọi phương thức riêng đó.

2. nếu ở trên được lặp lại ở nhiều nơi, bạn có thể xem xét việc tạo một lớp trừu tượng thực hiện Visitorvà chuyển hướng một tập hợp con của các visittriển khai thành một protected abstractphương thức chung .

3. tạo nhiều Visitorgiao diện:

   interface AOrB extends IConfigurationElementVisitor {
       <Result> Result accept(AOrBVisitor<Result> visitor);
   
       interface AOrBVisitor<Result> {
           Result visit(A a);
           Result visit(B b);
       }
   }
   
   interface ThisCouldBeOfTypeB extends IConfigurationElementVisitor {
       <Result> Result accept(ThisCouldBeOfTypeBVisitor<Result> visitor);
   
       interface ThisCouldBeOfTypeBVisitor<Result> {
           Result visit(B b);
           Result visit(ThisCouldBeOfTypeB visitable);
       }
   }
   
   class A implements AOrB, ThisCouldBeOfTypeB {...}
   
   class B implements AOrB, ThisCouldBeOfTypeB {...}
   
   class C implements ThisCouldBeOfTypeB {...}

Tôi nghĩ 3 là những gì bạn đang tìm kiếm. nó là đa hình tĩnh 100% và tạo cảnh báo trình biên dịch nếu một loại không được xử lý. Nhưng nhược điểm duy nhất tôi có thể nghĩ đến 3 là việc duy trì việc Visitable*triển khai có thể trở nên phức tạp nếu có nhiều Visitable*giao diện khác nhau .