Java: Mẫu ủy quyền và phương pháp được bảo vệ

Question

Tôi đã sử dụng mẫu ủy quyền để bọc một đối tượng được tạo bởi một nhà máy trong thư viện của bên thứ ba. Gần đây, thư viện đã thêm một phương thức được bảo vệ trong lớp cơ sở và lớp trình bao bọc của tôi không còn hoạt động nữa. Có ai có một giải pháp tốt mà không cần phải suy nghĩ để phản ánh?

Đây là trong thư viện bên thứ 3 và trong gói của họ,

public class Base { 
    public void foo(); 

    protected void bar(); // Newly added 
} 

này nằm trong gói của riêng tôi,

public class MyWrapper extends Base { 
    private Base delegate; 

    public MyWrapper(Base delegate) { 
     this.delegate = delegate; 
    } 

    public void foo() { 
     delegate.foo() 
    } 

    protected void bar() { 
     // Don't know what to do 
    } 
} 

EDIT: bài ban đầu của tôi là không rõ ràng. Hai lớp này nằm trong các gói khác nhau.

Để trả lời câu hỏi tại sao tôi cần ủy quyền. Đây là trường hợp sử dụng điển hình của mẫu Ủy quyền/Trình bao bọc và tôi không thể hiển thị nó ở đây trong một vài dòng mã. Thư viện trưng ra lớp cơ sở nhưng đối tượng thực sự từ nhà máy của chúng là lớp dẫn xuất của Base. Lớp thực tế thay đổi tùy thuộc vào cấu hình. Vì vậy, tôi không biết đại biểu là gì. Do đó mô hình kế thừa thẳng không hoạt động ở đây.

Answer 1

Access Levels 
Modifier Class Package Subclass World 
public  Y   Y  Y   Y 
protected Y   Y  Y   N 
no modifier Y   Y  N   N 
private  Y   N  N   N 

protected có package truy cập quá, bạn có thấy bất kỳ vấn đề cụ thể với điều này:

class Base { 
     public void foo(){}; 

     protected void bar(){}; // Newly added 
    } 

    class MyWrapper { 
     private Base delegate; 

     public MyWrapper(Base delegate) { 
      this.delegate = delegate; 
     } 

     public void foo() { 
      delegate.foo(); 
     } 

     protected void bar() { 
      // Don't know what to do 
      delegate.bar(); //since its in same package, it can be referenced, do you expect compile time error? 
     } 
    } 

Tiếp tục trong khi sử dụng mô hình người ủy nhiệm tại sao lớp wrapper mở rộng Base lớp, tôi không thấy cần thiết phải cụ thể vì bạn đã có một phiên bản Base. Đối với tôi, nó có vẻ như là một người trang trí.

Answer 2

Bạn không cần (hoặc không nên?) Ủy quyền cho phương thức thanh đó.

Nếu thư viện xác định phương thức được bảo vệ. Nó không muốn người dùng (tất nhiên trong gói khác nhau) để gọi phương thức đó, trừ khi tạo lớp con của loại đó. Bạn đang cố gắng phá vỡ quy tắc.

Nếu bạn muốn làm điều đó, có cách nào, bạn tạo một subtype của Base, nói SubBase, bạn tạo đối tượng của SubBase thay vì Base, sau đó vượt qua subBase để wrapper của bạn. sau đó bạn có thể trong wrapper của bạn bar() phương pháp viết delegate.bar() Bằng cách này, các SubBase thực sự là đại biểu, hoặc để nói wrapper của bạn được ủy SubBase không Base

Tôi nghĩ rằng bạn biết những gì tôi có ý nghĩa, vì vậy tôi chỉ không gõ mã ví dụ, chỉ dòng này tôi đoán là đủ:

//Wrapper 

private SubBase delegate; 

Bạn thấy trình bao bọc không cần thiết nữa nếu bạn có SubBase. Bạn thậm chí có thể xác định một số public void pubBar() trong số SubBase của mình và tại đó bạn gọi this.bar(). theo cách này, tất cả các đối tượng của SubBase đều có quyền truy cập vào phương thức được bảo vệ (via pubBar()), bất kể gói nào

Answer 3

Tôi có ấn tượng rằng lớp Base là giao diện hoặc lớp trừu tượng. Nếu vậy, bạn phải triển khai phương pháp bar(), ví dụ bằng cách sử dụng bất kỳ phương pháp nào trong số ba phương pháp được liệt kê bên dưới.

Side lưu ý, nếu Base là một lớp học bình thường, bạn không cần phải làm bất cứ điều gì (một cuộc gọi đến một thể hiện của MyWrapper.bar() thực sự sẽ dẫn đến một cuộc gọi đến Base.bar().

---

đại biểu cho đối tượng phụ huynh

Đây thường là một ý tưởng tốt nếu phương pháp bar() được sử dụng như một callback trong API bên thứ 3:

@Override 
protected void bar() { 
    delegate.bar(); 
} 

---

Không làm gì

Chỉ cần thêm một phương pháp có sản phẩm nào để tránh lỗi biên dịch:

@Override 
protected void bar() { 
    // silently ignored 
} 

---

Ném một ngoại lệ

dữ dội ngăn chặn bất kỳ việc sử dụng các mới phương pháp:

@Override 
protected void bar() { 
    throw new UnsupportedOperationException("not implemented"); 
} 

---

Là một mặt lưu ý, một cấu trúc mạnh mẽ hơn là để thích composition over inheritance để tách thực hiện của bạn từ việc thực hiện bên thứ 3, ví dụ

public class MyWrapper { // does not extend Base 
    private Base delegate; 

    public MyWrapper(Base delegate) { 
     this.delegate = delegate; 
    } 

    public void foo() { 
     delegate.foo() 
    } 

    // does not have to implement bar() 
} 

Answer 4

Tôi đang sử dụng Spring để tiêm Wrapper "Đại biểu cơ sở" từ mô-đun khác và để ủy nhiệm tôi đang sử dụng nhà máy sản xuất pojo.

<bean id="interfaceDelegate" factory-bean="DelegatePojoFactory" 
    factory-method="getMyDelegateInstance"> 
    <constructor-arg index="0"> 
     <value>OnLine</value> 
    </constructor-arg> 
</bean> 

<bean id="wrapper" class="path.Wrapper"> 
     <property name="delegate" ref="interfaceDelegate"></property> 
</bean> 

Answer 5

Nếu bạn không cần người ủy nhiệm của bạn là một ví dụ thực tế của lớp cơ sở, bạn chỉ có thể loại bỏ mối quan hệ đó:

public class MyWrapper { 
    private Base delegate; 

    public MyWrapper(Base delegate) { 
     this.delegate = delegate; 
    } 

    public void foo() { 
     delegate.foo() 
    } 

} 

Cho dù làm việc cho bạn là phụ thuộc nhiều vào khác của bạn và nhu cầu của bạn không hoàn toàn rõ ràng với tôi ngay bây giờ. Nếu thư viện định nghĩa giao diện cung cấp phương thức công khai được lớp cơ sở trừu tượng triển khai, bạn có thể triển khai thực hiện giao diện đó một cách hợp lý mà không kế thừa từ lớp cơ sở trừu tượng, điều này cũng có thể đáp ứng nhu cầu của bạn.