Được bảo vệ trong các giao diện

Tại sao tất cả các phương thức trong một interfaceđịnh nghĩa đều là ẩn public? Tại sao nó không cho phép một protectedphương pháp?

Bởi vì một giao diện được cho là có nghĩa là "những gì bạn có thể nhìn thấy từ bên ngoài lớp". Sẽ không có ý nghĩa nếu thêm các phương thức không công khai.

Mặc dù lý do thường được trích dẫn là "các giao diện xác định các API công khai", tôi nghĩ rằng đó là một sự đơn giản hóa quá mức. (Và nó cũng "có mùi" của logic vòng tròn.)

Sẽ không vô nghĩa nếu có các giao diện có hỗn hợp các công cụ sửa đổi truy cập; ví dụ một phần công khai và một phần hạn chế đối với các lớp khác trong cùng gói với giao diện. Trên thực tế, trong một số trường hợp, điều này có thể hữu ích, IMO.

Trên thực tế, tôi nghĩ rằng một phần lý do đằng sau việc làm cho các thành viên của một giao diện hoàn toàn công khai là nó làm cho ngôn ngữ Java đơn giản hơn :

• Các thành viên giao diện công khai ngầm sẽ đơn giản hơn đối với các lập trình viên. Đã bao nhiêu lần bạn thấy mã (các lớp) trong đó các công cụ sửa đổi truy cập phương thức được chọn dường như ngẫu nhiên? Rất nhiều lập trình viên "bình thường" gặp khó khăn trong việc hiểu cách tốt nhất để quản lý ranh giới trừu tượng của Java ¹ . Thêm công khai / bảo vệ / gói-riêng tư vào các giao diện làm cho chúng càng khó khăn hơn.

• Các thành viên giao diện công khai hoàn toàn đơn giản hóa đặc tả ngôn ngữ ... và do đó nhiệm vụ dành cho người viết trình biên dịch Java và những người triển khai các API phản chiếu.

Dòng suy nghĩ rằng "các giao diện xác định các API công khai" được cho là hệ quả (hoặc đặc điểm) của quyết định thiết kế ngôn ngữ đơn giản hóa ... chứ không phải ngược lại. Nhưng trên thực tế, hai luồng suy nghĩ có lẽ đã phát triển song song trong tâm trí của các nhà thiết kế Java.

Ở bất kỳ mức độ nào, phản hồi chính thức đối với RFE trong JDK-8179193 cho thấy rõ ràng rằng nhóm thiết kế Java đã quyết định ² rằng việc cho phép các protectedgiao diện làm tăng thêm độ phức tạp vì ít lợi ích thực sự. Kudos cho @skomisa để tìm ra bằng chứng .

Bằng chứng trong RFE giải quyết vấn đề. Đó là lý do chính thức tại sao điều đó đã không được thêm vào.

^{1 - Tất nhiên, các lập trình viên hàng đầu không gặp khó khăn gì với những điều này và có thể chào đón một bảng tính năng kiểm soát truy cập phong phú hơn. Nhưng, điều gì sẽ xảy ra khi mã của họ được giao cho người khác duy trì?}

^{2 - Bạn có thể không đồng ý với quyết định của họ hoặc lý do đã nêu của họ nhưng đó là tranh luận.}

Tôi phải nói rằng câu hỏi này đã được mở lại bằng cách giới thiệu các phương thức mặc định trong Java 8. Dự án mà tôi đang làm ngay bây giờ, tương tự như bản chất cơ sở của một giao diện, có ý định trừu tượng từ việc triển khai.

Có một số trường hợp mà tôi có thể đơn giản hóa mã của mình bằng phương pháp "được bảo vệ mặc định". Nó chỉ ra rằng điều đó không thực sự hoạt động, vì các giao diện vẫn bám vào logic Java 7. Một phương thức được bảo vệ thông thường không có ý nghĩa gì đặc biệt, vì những lý do đã đề cập ở trên; nhưng nếu một phương thức công khai mặc định yêu cầu một tài nguyên cấp thấp có khả năng sẽ không thay đổi và có thể được cung cấp bởi một phương thức được bảo vệ, thì đối với tôi, có vẻ như việc có công việc "được bảo vệ mặc định" sẽ không chỉ duy trì mã sạch hơn mà còn bảo vệ người dùng trong tương lai khỏi lạm dụng tình cờ.

(Điều đáng tiếc là điều này không làm thay đổi thực tế là tôi vẫn cần phải làm phức tạp quá mức mã của mình với các phần tóm tắt không cần thiết; nhưng tôi có ý định đưa một yêu cầu tính năng vào Oracle.)

Bởi vì các giao diện xác định các API công khai. Bất cứ thứ gì được bảo vệ là một chi tiết nội bộ không thuộc về giao diện.

Bạn có thể sử dụng các lớp trừu tượng với các phương thức trừu tượng được bảo vệ, nhưng các giao diện bị hạn chế đối với các phương thức chung và trường cuối cùng tĩnh công khai.

Có lẽ, bởi vì nó là một giao diện , tức là nó ở đó để cho khách hàng biết họ có thể làm gì với các phiên bản, thay vì nói cho họ biết những gì họ không thể làm.

Tôi mạnh mẽ cảm thấy rằng giao diện nên cho phép các phương pháp bảo vệ; ai nói rằng các giao diện phải hiển thị cho tất cả mọi người trên toàn thế giới? Theo quan điểm của bạn, nó có thể gây nhầm lẫn cho các lập trình viên "bình thường" (đọc là: không đủ năng lực): Phần lớn OOP là về cấu trúc đúng các đối tượng, lớp, gói, v.v., nếu một lập trình viên gặp khó khăn trong việc thực hiện tất cả những điều đó đúng cách, anh ta có vấn đề lớn hơn nhiều. Java được xây dựng cho loại điều đó.

Một số câu trả lời ở đây sử dụng lý luận vòng tròn để giải thích tại sao các phương thức giao diện không thể được bảo vệ: đó là bởi vì chúng phải ở chế độ công khai, nên rõ ràng là chúng không thể được bảo vệ!

Điều đó không giải thích được gì, nhưng may mắn thay, ai đó đã đưa ra yêu cầu nâng cao cho các phương thức được bảo vệ trong giao diện như một lỗi JDK vài năm trước, điều này làm sáng tỏ vấn đề:

Các phương pháp được bảo vệ trong giao diện: chia sẻ trên các gói

Vì các công cụ sửa đổi bị hạn chế một chút trong Java, cách chia sẻ các phương thức giữa các gói bị hạn chế đối với các phương thức công khai. Đôi khi việc công khai một phương thức là rất nguy hiểm, nhưng điều đó cần phải xảy ra vì thiếu công cụ sửa đổi thích hợp. Giải pháp của tôi khắc phục được hạn chế này.

Đặc tả ngôn ngữ java hiện không cho phép sửa đổi được bảo vệ cho các phương thức giao diện. Chúng tôi có thể tận dụng thực tế này và sử dụng các phương thức giao diện được bảo vệ cho tính năng mới này.

Nếu một phương thức giao diện được đánh dấu là bảo vệ và giao diện được thực hiện bởi một lớp trong gói khác, thì phương thức đó sẽ không cần công khai, nhưng cũng có thể là riêng tư hoặc ít nhất là gói được bảo vệ. Phương thức này có thể nhìn thấy được, những gì lớp khai báo nó sẽ hiển thị và có thể nhìn thấy thêm trong gói nguồn của giao diện (và các gói con?).

Bằng cách này, chúng tôi có thể chia sẻ các phương pháp nhất định trên các gói nổi tiếng.

Và đây là phản hồi cho yêu cầu nâng cao đó, đã bị đóng lại với trạng thái Won't fix:

Đề xuất này cố gắng giải quyết một vấn đề theo cách làm tăng thêm độ phức tạp và các trường hợp đặc biệt để đạt được ít lợi ích thực tế. Một cách điển hình để giải quyết vấn đề này là có một lớp riêng thực hiện giao diện công khai. Các phương thức triển khai là công khai, nhưng nằm trong một lớp riêng tư, vì vậy chúng vẫn là riêng tư.

Một giải pháp thay thế có sẵn bắt đầu từ Java 9 là đặt các lớp và phương thức ở chế độ công khai, nhưng trong một mô-đun có khả năng xuất đủ điều kiện sang các mô-đun "bạn bè" cụ thể thay vì được xuất ra công chúng.

Vì vậy, các bài học có thẩm quyền từ báo cáo lỗi đó là:

• Tình hình hiện tại sẽ không thay đổi; giao diện không bao giờ hỗ trợ protectedcác phương pháp.
• Lý do cho việc không hỗ trợ protectedcác phương thức trong các giao diện là nó " làm tăng thêm độ phức tạp và các trường hợp đặc biệt để đạt được ít thực tế ".
• Kể từ Java 9, có một cách tiếp cận thay thế để cung cấp quyền truy cập cấp độ gói vào các phương thức. Sử dụng Hệ thống mô-đun nền tảng Java (JPMS) để " đặt các lớp và phương thức ở chế độ công khai, nhưng trong một mô-đun có đủ điều kiện xuất sang các mô-đun" bạn bè "cụ thể thay vì được xuất ra công chúng ".

Vì một lớp triển khai phải triển khai TẤT CẢ các phương thức được khai báo trong giao diện của bạn, điều gì sẽ xảy ra nếu lớp triển khai của bạn nằm trong một gói khác?

Giao diện Nếu bạn muốn sử dụng thứ gì đó như bạn đã mô tả, hãy tiếp tục với các lớp trừu tượng hoặc giao diện lồng nhau.

Một đoạn trích từ Kiểu mã về các biến giao diện, nhưng vẫn áp dụng cho các phương thức:

Các biến giao diện được công khai hoàn toàn bởi vì các giao diện nhằm cung cấp Giao diện lập trình ứng dụng (API) mà các lập trình viên Java hoàn toàn có thể truy cập được để tham khảo và triển khai trong các ứng dụng của riêng họ. Vì một giao diện có thể được sử dụng trong các gói Java khác với giao diện của chúng, nên khả năng hiển thị công khai đảm bảo rằng mã chương trình có thể truy cập vào biến.

Khai báo các giao diện con bên trong là một phương pháp hay, nhưng protectedvề mặt kỹ thuật , bạn không thể khai báo các phương thức nội bộ của mình như trong một giao diện trong Java.

Tất nhiên, bạn có thể tạo một giao diện khác để sử dụng nội bộ, mở rộng giao diện công khai:

package yourpackage;

public interface PublicInterface {

    public void doThing1();

    public void doThing2();

    public void doThing3();

}

package yourpackage;

interface InternalInterface extends PublicInterface {

    void doAnyInternalThing1();

    void doAnyInternalThing2();

}

Bạn có thể sử dụng InternalInterfacegiao diện bên trong gói, nhưng bạn nên chấp nhận bất kỳ loại con nào của PublicInterface(trong các phương thức công khai):

package yourpackage;

public class SomeClass {

    public void someMethod(PublicInterface param) {
        if (param instanceof InternalInterface) {
            // run the optimized code
        } else {
            // run the general code
        }
    }

}

Bên ngoài gói người dùng có thể sử dụng PublicInterfacemà không gặp vấn đề gì.

Thông thường các lập trình viên tạo các lớp trừu tượng trong các tình huống tương tự. Tuy nhiên, trong trường hợp này chúng ta mất quyền lợi của đa thừa kế.

Tình huống duy nhất mà nó sẽ có ý nghĩa là khi bạn muốn hạn chế khả năng hiển thị trong cùng một gói. Tất cả các mục đích sử dụng khác protectedkhông được áp dụng. Cụ thể, protectedcác phương thức thường được sử dụng để cung cấp quyền truy cập vào một số chi tiết của các triển khai cấp thấp hơn cho con cháu. Nhưng tuyên bố điều đó trong một giao diện không có ý nghĩa, vì không có triển khai cấp thấp hơn để hiển thị.

Và ngay cả kịch bản gói không thực sự là giao diện.

Để đạt được những gì bạn có thể muốn, bạn cần hai giao diện, một để sử dụng nội bộ và một giao diện mà bạn để lộ trong API công khai. (Có thể có cái bên trong, nhưng không nhất thiết phải mở rộng cái công khai.) Hoặc, như những người khác đã chỉ ra, một lớp cha trừu tượng.

Các phương thức được bảo vệ luôn có thể được truy cập bởi lớp con chỉ khi lớp con mở rộng lớp cơ sở.

Trong trường hợp giao diện, lớp con không bao giờ mở rộng giao diện. Nó thực hiện giao diện.

Các phương pháp được bảo vệ có thể truy cập thông qua mở rộng và không phải thực hiện .

Giao diện có nghĩa là để hiển thị các phương thức với thế giới bên ngoài . Vì vậy, các phương pháp này là công khai về bản chất. Tuy nhiên, nếu bạn muốn giới thiệu tính trừu tượng trong cùng một họ các lớp, bạn có thể tạo một mức độ trừu tượng khác giữa giao diện và lớp thực thi, tức là một lớp trừu tượng. Dưới đây là một ví dụ.

public interface MyInterface {
    public void publicMethod(); // needs to be public
}

public abstract class MyAbstractClass implements MyInterface {
    @Override
    public void publicMethod() {
        protectedMethod(); // you can call protected method here
        // do other stuff
    }
    protected abstract void protectedMethod(); // can be protected
}

public class MyClass extends MyAbstractClass {
    @Override
    protected void protectedMethod() {
        // implement protected method here, without exposing it as public
    }
}