Tại sao một tệp nguồn Java có tên của lớp công khai mà nó chứa?


14

Tôi là một người mới học Java. Trong Java, mọi tệp nguồn phải chứa một lớp chung và tệp nguồn đó phải có cùng tên với lớp chung đó. Hơn nữa, không có tệp nguồn nào có thể chứa hai lớp công khai. Tại sao hạn chế này?


4
Không có chi tiết cụ thể, đây là một tạo tác thiết kế lịch sử theo cách Java được thiết kế. Các ngôn ngữ được thiết kế gần đây, như C #, trong khi tương tự như Java, không có hạn chế này.
gahooa

13
Không phải là để thực thi các thực hành tốt nhất? Tôi nghĩ rằng đây là lý do duy nhất. Trong C #, bạn không có hạn chế này ở cấp độ kỹ thuật, nhưng StyleCop vẫn sẽ khiếu nại nếu tên tệp và tên lớp không khớp hoặc nếu bạn có một vài lớp trong cùng một tệp. Visual Studio cũng rất khuyến khích quan hệ tệp lớp (nghĩ sơ đồ lớp tạo tệp cho bạn hoặc khi bạn đổi tên tệp .cs, Visual Studio sẽ hỏi bạn nếu bạn cũng muốn cấu trúc lại tên của lớp).
Arseni Mourzenko

Trong một ngôn ngữ biên dịch kiểu cũ, trình liên kết tìm thấy tất cả các tham chiếu và ký hiệu bên ngoài. Nhưng Java không được liên kết - bạn có thể tải các lọ trong thời gian chạy nếu bạn muốn. Nếu không có bước liên kết, cố gắng ánh xạ tên lớp đến các vị trí trong đường dẫn lớp sẽ nhanh hơn rất nhiều nếu bạn biết tên tệp nào cần tìm.
Paul Tomblin

4
@gahooa nó không phải là một tạo tác thiết kế, nó là một quyết định thiết kế có chủ ý. Điều này làm cho nhiều thứ dễ dàng hơn nhiều.

1
Còn việc sử dụng grep thì sao?
người dùng

Câu trả lời:


19

Trong một trong những Bản tin của Chuyên gia Java của mình, Heinz Kabutz đã đào sâu thông số kỹ thuật của Ngôn ngữ Oak . Anh ấy viết:

Tại sao mỗi lớp công khai trong một tệp riêng biệt? (Phần 1)

Đây là một câu hỏi mà tôi thường xuyên được hỏi trong các khóa học của mình. Cho đến bây giờ tôi chưa có câu trả lời tốt cho câu hỏi này. Trong phần 1, chúng tôi đọc: "Mặc dù mỗi đơn vị biên dịch Oak có thể chứa nhiều lớp hoặc giao diện, tối đa một lớp hoặc giao diện cho mỗi đơn vị biên dịch có thể được công khai".

Trong thanh bên, nó giải thích tại sao: "Hạn chế này chưa được trình biên dịch thực thi, mặc dù nó cần thiết để nhập gói hiệu quả"

Điều này khá rõ ràng - giống như hầu hết mọi thứ là một khi bạn biết lý do thiết kế - trình biên dịch sẽ phải thực hiện thêm thông qua tất cả các đơn vị biên dịch (tệp .java) để tìm ra các lớp đang ở đâu và điều đó sẽ khiến quá trình biên dịch chậm hơn .

http://www.javaspecialists.eu/archive/Issue055.html


1
Để biên dịch nhanh hơn một chút ? Có thật không? Không phải vì nó làm cho mã của bạn có tổ chức hơn nhiều? Tôi rất nghi ngờ đây là câu trả lời chính xác.
BlueRaja - Daniel Pflughoeft

1
@ BlueRaja-DannyPflughoeft Năm 1998, tôi chắc chắn rằng nó đã tạo ra sự khác biệt lớn hơn nhiều
TheLQ

8

Những lý do tôi có thể nghĩ ra

  • Làm cho việc tìm kiếm các lớp khác dễ dàng hơn một chút cho trình biên dịch ngay từ đầu vì nó không phải tìm kiếm tất cả hàng ngàn tệp lớp có khả năng cho một lớp công khai ngẫu nhiên, nó chỉ có thể đi đến tệp.
    • Điều này có lẽ không còn quan trọng nữa mà chỉ bắt đầu quy ước sớm không bao giờ thay đổi
  • Trong quá trình biên dịch, việc thay đổi tệp chỉ ảnh hưởng đến tệp đó. Nếu có nhiều lớp thì mọi thứ phải được biên dịch lại
  • Thực hành tốt nhất - Có nhiều lớp công khai trong cùng một tệp làm cho mọi thứ trở nên khó hiểu. Mục đích của tập tin là tổ chức mã nguồn, mục đích của thư mục là tổ chức các tập tin. Nếu tất cả các lớp của một gói cụ thể nằm trong một siêu tệp 100 MB thì bạn đã mất tất cả các lợi thế và không nhận được bất kỳ lợi ích nào của các tệp (cộng thêm nhiều vấn đề đau đầu khi chỉnh sửa)

1
Các lớp và giao diện không nhất thiết phải biểu thị mức phân chia tự nhiên nhất cho mã nguồn. Việc có hàng ngàn dòng mã được đưa vào một tệp là bất tiện, nhưng cũng không có 100 dòng nội dung "thực" (không bao gồm các bình luận hoặc chỉ thị của trình biên dịch trùng lặp) trong một tá tệp nguồn. Tôi tự hỏi làm thế nào nó sẽ có tác dụng nếu một file có tên cho kiểu phải hoặc chứa các định nghĩa hoặc khác xác định các tập tin đó không?
supercat
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.