Tuyên bố cuối cùng tĩnh công khai của một biến mẫu trong Giao diện JAVA

Question

Tại sao chúng ta sử dụng khai báo public static final của các biến mẫu trong Giao diện Java?
Tất cả các biến được ẩn hoàn toàn public static final trong Giao diện Java.
Có thực hành mã hóa tốt để sử dụng public static final trong biến không đổi mặc dù nó được khai báo bên trong Giao diện.

Ví dụ:

public interface TestInterface{ 

public static final String EX_CONSTANT = "ABC"; 
public static final int EX_INT_CONSTANT = 5; 
public static final double EX_DOUBLE = 5.0; 
public static final Integer EX_INTEGER = 10; 

} 

Answer 1

Sử dụng cú pháp thống nhất trong cả hai lớp và giao diện đơn giản hóa việc tái cấu trúc.

Bạn có thể muốn để biến bạn thành một interfaceclass nơi nào đó trong tương lai, hoặc di chuyển các lĩnh vực này vào một lớp học, và bạn sẽ nhận được một sự khác biệt ngữ nghĩa nếu bạn bỏ qua một số lĩnh vực được xác định mà không public static final (tất nhiên, chúng tôi có các công cụ cho tái cấu trúc, nhưng dù sao).

Tôi nghĩ rằng nó giống như sự hỗ trợ của chú thích @Overriden cho việc triển khai các phương thức được khai báo trong giao diện được giới thiệu trong Java 6 - nó dư thừa ở dạng hiện tại của nó, nhưng có thể hữu ích trong trường hợp tái cấu trúc.

Answer 2

IMO, giao diện là một hợp đồng. Một khi các biến được khai báo hoặc xác định chúng sẽ không thay đổi. Đó là lý do tại sao chúng tôi thường làm cho chúng public static final.

Khả năng đọc là một yếu tố khác khiến việc khai báo thừa.

Answer 3

Tôi không nghĩ vậy. Tất cả các giao diện biến là kết quả tĩnh công khai hoàn toàn, do đó không có ý nghĩa để đánh dấu chúng giống nhau.

Answer 4

Phải thừa nhận rằng điều đó là thừa. Thông thường mọi người chỉ không biết rằng họ hoàn toàn là public static final và tuyên bố nó. Ditto với những thứ như tuyên bố:

public abstract interface Test { // Interfaces are always abstract 
    public void testMethod(); // Interface methods are always public 
    abstract void anotherTestMethod(); // Also redundant 
} 

Thông thường nó chỉ nắm để thực tế là mọi người không biết rằng họ không có phải khai báo nó một cách này hay cách khác. Tôi đã từng nói chuyện với ai đó (một lập trình viên dày dặn) nghĩ rằng trường hợp default trong switch là bắt buộc hoặc nó sẽ không biên dịch.

Điều đó đang được nói, lập luận duy nhất được thực hiện để thêm chúng là chúng làm rõ khả năng hiển thị thực tế của chúng và không thực sự là gì. Đó là vấn đề về khả năng đọc và làm rõ, và có hay không ghi chú để bao gồm chúng là không liên quan về cách nó thực sự cư xử.

Answer 5

Khi bạn làm việc trong nhóm lập trình viên, bạn sẽ tìm thấy người lập trình cơ sở không biết thực tế là mặc định các biến là public static final trong giao diện và thấy các biến được khai báo theo cách đó sẽ cung cấp cho chúng thêm thông tin về giao diện và sử dụng các biến của nó.

Answer 6

Bạn chính xác: không cần thiết. Tôi không muốn thêm cú pháp thừa vào bất kỳ lúc nào. Tuy nhiên, thực tế không có các học viên của nó. Một số cũng muốn thêm các dấu ngoặc đơn xung quanh các biểu thức trả về, trên cơ sở dự báo rằng nó giống như một câu lệnh 'if'; thêm dấu ngoặc đơn để 'làm rõ' các biểu thức số học mà một học sinh lớp ba sẽ hiểu; vv Đó là tất cả các phần của tấm thảm phong phú của cuộc sống.

Answer 7

Từ cuốn sách java hiệu quả bởi Joshua Bloch

mục 19: Sử dụng giao diện duy nhất để xác định các loại

Khi một lớp thực hiện một giao diện, giao diện đóng vai trò như một loại có thể được được sử dụng để chỉ các cá thể của lớp. Do đó, một lớp thực hiện một giao diện do đó nên nói điều gì đó về một khách hàng có thể làm gì với các trường hợp của lớp . Không thể xác định một giao diện cho bất kỳ mục đích nào khác.

Một loại giao diện không thực hiện được thử nghiệm này là giao diện không đổi. Giao diện như vậy không chứa phương thức nào; nó chỉ bao gồm các trường cuối cùng tĩnh, mỗi trường xuất một hằng số. Các lớp sử dụng các hằng số này thực hiện giao diện để tránh sự cần thiết phải đủ điều kiện tên không đổi với tên lớp. Dưới đây là một ví dụ:

// Constant interface antipattern - do not use! 
public interface PhysicalConstants { 
    // Avogadro's number (1/mol) 
    static final double AVOGADROS_NUMBER = 6.02214199e23; 
    // Boltzmann constant (J/K) 
    static final double BOLTZMANN_CONSTANT = 1.3806503e-23; 
    // Mass of the electron (kg) 
    static final double ELECTRON_MASS = 9.10938188e-31; 
} 

Các mô hình giao diện thường xuyên là một người nghèo sử dụng các giao diện. Đó là một lớp sử dụng một số hằng số nội bộ là một chi tiết thực hiện. Triển khai giao diện không đổi làm cho chi tiết triển khai này bị rò rỉ vào API được xuất của lớp học. Nó là không có hậu quả cho người dùng của một lớp mà lớp thực hiện một giao diện không đổi. Trong thực tế, nó thậm chí có thể gây nhầm lẫn cho họ. Tệ hơn nữa, nó đại diện cho một cam kết: nếu trong bản phát hành trong tương lai, lớp được sửa đổi để nó không còn cần phải sử dụng các hằng số, nó vẫn phải triển khai giao diện để đảm bảo khả năng tương thích nhị phân. Nếu lớp nonfinal thực hiện một giao diện không đổi, tất cả các lớp con của nó sẽ có các không gian tên bị ô nhiễm bởi các hằng số trong giao diện.

Có một số giao diện không đổi trong các thư viện nền tảng Java, chẳng hạn như java.io.ObjectStreamConstants. Các giao diện này nên được coi là bất thường và không được mô phỏng.

Nếu bạn muốn xuất các hằng số, có một số lựa chọn hợp lý. Nếu hằng số được gắn chặt với một lớp hoặc giao diện hiện có, bạn nên thêm chúng vào lớp hoặc giao diện. Ví dụ, tất cả các lớp nguyên thủy số nguyên đóng hộp, chẳng hạn như Integer và Double, xuất các hằng số MIN_VALUE và MAX_VALUE. Nếu các hằng số được xem tốt nhất là thành viên của một loại được liệt kê, bạn nên xuất chúng với loại enum (Mục 30). Nếu không, bạn nên xuất các hằng số với lớp tiện ích không thể khôi phục (khoản 4). Dưới đây là một phiên bản lớp tiện ích của PhysicalConstants ví dụ trên:

// Constant utility class 
package com.effectivejava.science; 

public class PhysicalConstants { 
    private PhysicalConstants() { 
    } // Prevents instantiation 

    public static final double AVOGADROS_NUMBER = 6.02214199e23; 
    public static final double BOLTZMANN_CONSTANT = 1.3806503e-23; 
    public static final double ELECTRON_MASS = 9.10938188e-31; 
} 

Thông thường một lớp tiện ích đòi hỏi khách hàng để đủ điều kiện tên thường xuyên với một tên lớp , ví dụ, PhysicalConstants.AVOGADROS_NUMBER. Nếu bạn thực hiện việc sử dụng hằng số các hằng số được xuất bởi lớp tiện ích, bạn có thể tránh sự cần thiết phải đủ điều kiện cho các tên hằng số bằng cách sử dụng cơ sở nhập tĩnh, được giới thiệu trong bản phát hành 1.5:

// Use of static import to avoid qualifying constants 
import static com.effectivejava.science.PhysicalConstants.*; 
public class Test { 
    double atoms(double mols) { 
     return AVOGADROS_NUMBER * mols; 
    } 
... 
// Many more uses of PhysicalConstants justify static import 
} 

Nói tóm lại, giao diện nên chỉ được sử dụng để xác định các loại. Không được sử dụng để xuất các hằng số.