Tôi đang học Java và chỉ thấy rằng Giao diện có thể có các trường, là trường tĩnh công khai và trường cuối cùng. Tôi chưa thấy bất kỳ ví dụ nào về những điều này cho đến nay. Một số trường hợp sử dụng của các Hằng số Giao diện này là gì và tôi có thể xem một số trường hợp trong Thư viện Chuẩn Java không?
Câu trả lời:
Đặt các thành viên tĩnh vào một giao diện (và triển khai giao diện đó) là một việc làm không tốt và thậm chí còn có một cái tên cho nó, Bộ phản vật chất giao diện không đổi , xem Java hiệu quả , Mục 17:
Mẫu giao diện không đổi là cách sử dụng giao diện kém . Việc một lớp sử dụng một số hằng số bên trong là một chi tiết triển khai. Việc triển khai một giao diện không đổi khiến chi tiết triển khai này bị rò rỉ vào API đã xuất của lớp. Không có hậu quả gì đối với 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. Trên thực tế, nó thậm chí có thể khiến họ nhầm lẫn. Tệ hơn nữa, nó đại diện cho một cam kết: nếu trong một bản phát hành trong tương lai, lớp được sửa đổi để nó không cần sử dụng các hằng số nữa, nó vẫn phải triển khai giao diện để đảm bảo tính tương thích nhị phân. Nếu một lớp nonfinal triển khai một giao diện không đổi, tất cả các lớp con của nó sẽ có không gian tên của chúng 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. Những giao diện này nên được coi là dị thường và không nên được mô phỏng.
Để tránh một số cạm bẫy của giao diện không đổi (vì bạn không thể ngăn mọi người triển khai nó), nên ưu tiên một lớp thích hợp với một hàm tạo riêng (ví dụ mượn từ Wikipedia ):
public final class Constants {
private Constants() {
// restrict instantiation
}
public static final double PI = 3.14159;
public static final double PLANCK_CONSTANT = 6.62606896e-34;
}Và để truy cập các hằng số mà không cần phải đủ điều kiện cho chúng (tức là không cần phải đặt trước chúng bằng tên lớp), hãy sử dụng nhập tĩnh (kể từ Java 5):
import static Constants.PLANCK_CONSTANT;
import static Constants.PI;
public class Calculations {
public double getReducedPlanckConstant() {
return PLANCK_CONSTANT / (2 * PI);
}
}" Mẫu giao diện không đổi là cách sử dụng giao diện kém "
Bất cứ ai đã đặt ra giả thuyết này, dù có thể là một bậc thầy, họ đã đưa ra giả thuyết này trên cơ sở nhu cầu tiếp tục thực hiện những thói quen và thực hành xấu một cách hiệu quả. Giả thuyết dựa trên việc thúc đẩy tính hợp lệ của các thói quen thiết kế phần mềm xấu.
Tôi đã viết một phản hồi phản bác lại giả thuyết đó ở đây: Cách tốt nhất để triển khai các hằng số trong Java là gì? giải thích sự vô căn cứ của giả thuyết này.
Trong 10 năm, câu hỏi đó vẫn để ngỏ, cho đến khi nó được đóng lại trong vòng 2 giờ sau khi tôi đăng lý do của mình để bác bỏ giả thuyết này, do đó làm cho những người theo đuổi giả thuyết sai lầm này một cách thân thiết để tranh luận.
Đây là những điểm tôi đã bày tỏ chống lại giả thuyết
Cơ sở để giữ giả thuyết này là sự cần thiết của các phương pháp và các quy tắc HẠN CHẾ để đối phó với các tác động của các thói quen và phương pháp luận phần mềm xấu.
Những người ủng hộ quan điểm " Mô hình giao diện không đổi là cách sử dụng giao diện kém" không thể đưa ra bất kỳ lý do nào khác ngoài lý do gây ra bởi nhu cầu đối phó với tác động của những thói quen và tập quán xấu đó.
Giải quyết vấn đề cơ bản.
Và tại sao không tận dụng và khai thác mọi tính năng ngôn ngữ của cấu trúc ngôn ngữ Java để thuận tiện cho riêng bạn. Không cần áo khoác. Tại sao lại phát minh ra các quy tắc để ngăn cản lối sống kém hiệu quả của bạn để phân biệt đối xử và buộc những lối sống hiệu quả hơn?
là tổ chức thông tin. Thông tin làm trung gian cho quá trình, và hành vi của thông tin đó trước tiên phải được hiểu, cùng với cái gọi là quy tắc kinh doanh - trước khi thiết kế hoặc bổ sung các giải pháp cho quy trình. Phương pháp tổ chức thông tin như vậy được gọi là chuẩn hóa dữ liệu cách đây vài thập kỷ.
Khi đó, chỉ có thể thực hiện được kỹ thuật của một giải pháp bởi vì việc điều chỉnh mức độ chi tiết và mô đun của các thành phần của giải pháp với mức độ chi tiết và mô đun của các thành phần thông tin là chiến lược tối ưu.
Có hai hoặc ba trở ngại đáng kể đối với việc tổ chức thông tin.
Sự thiếu nhận thức về sự cần thiết của "chuẩn hóa" mô hình dữ liệu.
Các tuyên bố của EF Codd về chuẩn hóa dữ liệu còn thiếu sót, khiếm khuyết và không rõ ràng.
Mốt mới nhất giả mạo là kỹ thuật nhanh là quan niệm sai lầm rằng người ta không nên lập kế hoạch và điều kiện tổ chức các mô-đun trước vì bạn có thể cấu trúc lại khi bạn tiếp tục. Việc tái cấu trúc và thay đổi liên tục mà không bị cản trở bởi những khám phá trong tương lai được sử dụng làm cái cớ. Sau đó, các khám phá cơ bản về hành vi của thông tin quá trình, bằng cách sử dụng các thủ thuật kế toán để trì hoãn lợi nhuận và cạnh tranh, do đó kiến thức thiết yếu và việc xử lý chúng được coi là không cần thiết bây giờ.
Đừng tạo ra các quy tắc hoặc đưa ra bất kỳ phản đối nào chống lại nó chỉ vì bạn yêu thích thói quen lập trình chạy và chạy đặc biệt của mình.
Không cấm sở hữu súng với lý do có người không biết cầm súng hoặc dễ lạm dụng súng.
Nếu các quy tắc bạn xây dựng dành cho những người mới lập trình không thể viết mã chuyên nghiệp và bạn tự đếm mình trong số đó thì hãy nói như vậy - đừng khai báo fatwa của bạn là áp dụng cho các mô hình dữ liệu chuẩn hóa đúng cách.
Tôi không quan tâm ý định ban đầu của những người sáng lập ra Hiến pháp Hoa Kỳ là gì. Tôi không quan tâm đến những ý định bất thành văn chưa được sửa đổi. Tôi chỉ quan tâm đến những gì được hệ thống hóa về văn bản trong Hiến pháp thành văn và cách tôi có thể khai thác chúng cho hoạt động hiệu quả của xã hội.
Tôi chỉ quan tâm đến những gì mà các thông số kỹ thuật của ngôn ngữ / nền tảng Java cho phép tôi và tôi dự định khai thác chúng một cách đầy đủ để đủ cho tôi một phương tiện để thể hiện các giải pháp phần mềm của mình một cách hiệu quả và hiệu quả. Không cần áo khoác.
Nó yêu cầu viết thêm mã để ánh xạ tham số thành giá trị. Thực tế là những người sáng lập Java đã không cung cấp ánh xạ tham số-giá trị mà không có văn bản của bạn rằng mã ánh xạ chứng tỏ Hằng số Enum cũng giống như việc sử dụng ngôn ngữ Java ngoài ý muốn.
Đặc biệt là vì bạn không được khuyến khích chuẩn hóa và thành phần hóa các thông số của mình, nên sẽ có ấn tượng sai rằng các thông số được trộn vào túi Enum có cùng thứ nguyên.
Đừng quên điều đó. Nếu bạn đã thiết kế và chuẩn hóa mô hình dữ liệu của mình và chúng bao gồm các hằng số, thì những hằng số đó là hợp đồng. Nếu bạn không chuẩn hóa mô hình dữ liệu của mình, thì bạn nên tuân theo những điều đã được đưa ra về cách thực hành mã hóa hạn chế để đối phó với thói quen xấu đó.
Do đó, Interfaces là một cách hoàn hảo để thực hiện hợp đồng của Constants.
Đúng vậy. Bất kỳ ai cũng có thể vô tình triển khai bất kỳ giao diện nào. Sẽ không có gì cản đường những lập trình viên vô tình như vậy.
Không đặt các nghị định hạn chế để bảo vệ các hoạt động xấu được cho là có thể gây rò rỉ các thông số không được rút gọn / đi lạc vào API. Giải quyết vấn đề cơ bản, thay vì đổ lỗi cho Hằng số giao diện.
Một lập trình viên hoạt động bình thường và HIỆU QUẢ không phải ở đó để chứng minh cô ấy có thể ở dưới nước trong bao lâu, cô ấy có thể đi được bao xa trong cái nóng chói chang hoặc mưa giông ẩm ướt. Cô là sử dụng một công cụ hiệu quả như một chiếc xe hơi hoặc xe buýt hoặc ít nhất là một chiếc xe đạp để mất 10 dặm của mình để công việc hàng ngày.
Đừng đặt ra những hạn chế đối với các lập trình viên đồng nghiệp chỉ vì bạn có một nỗi ám ảnh về chủ nghĩa khổ hạnh bí truyền với lập trình ít IDE.
OSGI là một khuôn khổ như vậy. Và sắc lệnh chống lại Hằng số giao diện cũng vậy.
Hằng số giao diện là một cách hiệu quả và hiệu quả để đưa vào Hợp đồng các thành phần được thiết kế tốt và chuẩn hóa của mô hình dữ liệu.
Hằng số giao diện trong một giao diện riêng được đặt tên thích hợp được lồng trong một tệp lớp cũng là một phương pháp hay để nhóm tất cả các hằng số riêng của bạn thay vì phân tán chúng trên toàn bộ tệp.
Tôi đã xem lại câu hỏi cũ này vài lần và câu trả lời được chấp nhận vẫn khiến tôi bối rối. Sau rất nhiều suy nghĩ, tôi nghĩ câu hỏi này có thể được làm rõ hơn.
Chỉ cần so sánh chúng:
public final class Constants {
private Constants() {
// restrict instantiation
}
public static final double PI = 3.14159;
public static final double PLANCK_CONSTANT = 6.62606896e-34;
}vs
public interface Constants {
double PI = 3.14159;
double PLANCK_CONSTANT = 6.62606896e-34;
}Cách sử dụng giống nhau. Mã ít hơn nhiều.
Tôi nghĩ câu trả lời của @Pascal Thivent đã nhấn mạnh sai, đây là phiên bản của tôi về nó:
Đưa các thành viên tĩnh vào một giao diện ( và triển khai giao diện đó ) là một việc làm không tốt.
Trích dẫn từ Java hiệu quả có giả định về giao diện không đổi được thực thi bởi những người khác, điều mà tôi nghĩ không nên (và sẽ không) xảy ra.
Khi bạn tạo một giao diện cố định có tên như thế nào đó Constants, nó không nên được thực hiện bởi bất kỳ ai. (mặc dù có thể về mặt kỹ thuật, đó là vấn đề duy nhất ở đây)
Thư viện tiêu chuẩn không có khả năng sử dụng sai thiết kế, vì vậy bạn sẽ không thấy bất kỳ thứ gì ở đó.
Tuy nhiên , đối với các dự án hàng ngày của các nhà phát triển bình thường, sử dụng giao diện hằng là dễ dàng hơn nhiều bởi vì bạn không cần phải lo lắng về static, final, empty constructor, vv, và nó sẽ không gây ra bất kỳ vấn đề thiết kế xấu. Nhược điểm duy nhất tôi có thể nghĩ đến là nó vẫn có tên là "giao diện", nhưng không có gì hơn thế.
Cuối cùng, tôi nghĩ rằng mọi người chỉ trích dẫn từ sách, và đưa ra ý kiến và biện minh cho lập trường của họ. Không ngoại lệ cho tôi. Có thể quyết định vẫn phụ thuộc vào các nhà phát triển của mỗi dự án. Chỉ cần tiếp tục sử dụng nó nếu bạn cảm thấy thoải mái. Điều tốt nhất chúng tôi có thể làm là làm cho nó nhất quán trong suốt dự án .
publiccũng có thể được bỏ qua vì nó là một giao diện, làm cho nó đơn giản là double PI = 3.14159;Cách sử dụng Constants.PIkhông cần lớp sử dụng này để triển khai Constantsgiao diện! Tôi nghĩ cách tiếp cận giao diện sạch hơn nhiều về cách sử dụng, IMHO
Joshua Bloch, "Java - Hướng dẫn Ngôn ngữ Lập trình Hiệu quả":
Mẫu giao diện không đổi là cách sử dụng giao diện kém. Việc một lớp sử dụng một số hằng trong nội bộ là một chi tiết triển khai. Việc triển khai một giao diện không đổi khiến chi tiết triển khai này bị rò rỉ vào API đã xuất của lớp. Không có hậu quả gì đối với 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. Trên thực tế, nó thậm chí có thể khiến họ nhầm lẫn. Tệ hơn nữa, nó đại diện cho một cam kết: nếu trong một bản phát hành trong tương lai, lớp được sửa đổi để nó không cần sử dụng các hằng số nữa, nó vẫn phải triển khai giao diện để đảm bảo tính tương thích nhị phân. Nếu một lớp nonfinal triển khai một giao diện không đổi, tất cả các lớp con của nó sẽ có vùng tên của chúng bị ô nhiễm bởi các hằng số trong giao diện.
Chúng hữu ích nếu bạn có các hằng số chung sẽ được sử dụng trong các lớp triển khai giao diện.
Đây là một ví dụ: http://www.javapractices.com/topic/TopicAction.do?Id=32
Nhưng lưu ý rằng phương pháp được khuyến nghị là sử dụng nhập tĩnh thay vì hằng số trong giao diện. Đây là tài liệu tham khảo: http://www.javapractices.com/topic/TopicAction.do?Id=195
Có những câu trả lời rất có tiếng vang.
Nhưng tôi có một số suy nghĩ về câu hỏi này. (có thể sai)
Theo ý kiến của tôi, các trường trong một giao diện, không nên là hằng số cho toàn bộ dự án, chúng chỉ là phương tiện cho giao diện và các giao diện mở rộng nó và các lớp triển khai các giao diện này hoặc có mối quan hệ chặt chẽ với chúng. Chúng nên được sử dụng trong một phạm vi nhất định không phải toàn cầu.
Hai điểm về giao diện:
Một giao diện mô tả một tập hợp con của những gì một đối tượng triển khai nó có thể làm. (Đây là trực giác)
Một giao diện mô tả các hằng số chung theo sau là các đối tượng triển khai nó.
Vì vậy, tôi nghĩ nếu Giao diện Hằng số không được sử dụng cho các hằng số toàn cục , thì có thể chấp nhận được:
implementsnó (và tất nhiên, sử dụng các hằng số chung này trong việc triển khai).Thí dụ:
interface Drawable {
double GOLDEN_RATIO = 1.618033988;
double PI = 3.141592653;
...
// methods
...
}
public class Circle implements Drawable {
...
public double getCircumference() {
return 2 * PI * r;
}
}
void usage() {
Circle circle = new Circle(radius: 3.0);
double maxRadius = 5.0;
if ( circle.getCircumference() < 2 * Circle.PI * maxRadius ) {
...
}
}Trong ví dụ này:
Circle implements Drawable, bạn biết ngay rằng Circlenó có thể phù hợp với các hằng được định nghĩa trong đó Drawable, nếu không, họ phải chọn một tên xấu hơn vì những tên tốt PIvà GOLDEN_RATIOđã được sử dụng!Drawableđối tượng này phù hợp với cụ thể PIvà GOLDEN_RATIOđược xác định trong Drawable, có thể có những đối tượng không Drawablecó độ chính xác khác nhau của pi và tỷ lệ vàng.Các javax.swing.SwingConstantsgiao diện là một ví dụ trong đó có lĩnh vực tĩnh được sử dụng trong các tầng lớp swing. Điều này cho phép bạn dễ dàng sử dụng những thứ như
this.add(LINE_START, swingcomponent);this.add(this.LINE_START, swingcomponent); hoặc là this.add(SwingComponents.LINE_START, swingcomponent);Tuy nhiên, giao diện này không có các phương thức ...
Tôi đã xem qua câu hỏi này và nghĩ rằng tôi sẽ thêm một cái gì đó chưa được đề cập. Nói chung, tôi đồng ý với câu trả lời của Pascal ở đây . Tuy nhiên, tôi không nghĩ rằng các hằng số trên một giao diện "luôn luôn" là một phản vật chất.
Ví dụ: nếu các hằng số mà bạn đang xác định là một phần của hợp đồng cho giao diện đó, tôi nghĩ rằng giao diện là một nơi tuyệt vời cho các hằng số. Trong một số trường hợp, việc xác thực các thông số của bạn một cách riêng tư là không phù hợp mà không để lộ hợp đồng cho người dùng triển khai của bạn. Nếu không có hợp đồng công khai, người dùng chỉ có thể đoán bạn đang xác thực cái gì, không cần dịch ngược lớp và đọc mã của bạn.
Vì vậy, nếu bạn triển khai một giao diện và giao diện có các hằng số mà bạn sử dụng để đảm bảo các hợp đồng của mình (chẳng hạn như phạm vi số nguyên), thì người dùng trong lớp của bạn có thể chắc chắn rằng họ đang sử dụng phiên bản giao diện một cách chính xác bằng cách kiểm tra các hằng số trong giao diện chúng tôi. Điều này sẽ là không thể nếu các hằng là riêng tư đối với việc triển khai của bạn hoặc việc triển khai của bạn là gói riêng tư hoặc một cái gì đó.
Tôi sử dụng hằng số giao diện khi xử lý các hằng số được chia sẻ giữa các lớp.
public interface TestConstants
{
String RootLevelConstant1 = "RootLevelConstant1";
interface SubGroup1
{
String SubGroupConstant1 = "SubGroup1Constant1";
String SubGroupConstant2 = "SubGroup1Constant2";
}
interface SubGroup2
{
String SubGroupConstant1 = "SubGroup2Constant1";
String SubGroupConstant2 = "SubGroup2Constant2";
}
}Nhóm là một tài sản lớn, đặc biệt là với một tập hợp lớn các hằng số.
Để sử dụng, bạn chỉ cần xâu chuỗi chúng lại với nhau:
System.out.println(TestConstants.SubGroup1.SubGroupConstant1);
System.out.println(TestConstants.SubGroup2.SubGroupConstant1);
System.out.println(TestConstants.RootLevelConstant1);