Là quy ước tên gói Java có thiếu sót? [đóng cửa]

Chúng ta đều quen thuộc với quy ước tên gói Java để chuyển tên miền xung quanh. Tức là www.evilcorp.com, theo quy ước, đã chọn để có các gói java của họ com.evilcorp.stuff.

Càng ngày tôi càng chán ngấy việc này. Là một lập trình viên thương mại, tôi gặp phải nhiều lần rằng tên gói phần mềm hoàn toàn không liên quan do một số thương hiệu, mua lại hoặc tương tự.

Trong thế giới mở có ít thay đổi tên hơn nên có ý nghĩa. Tuy nhiên, dường như thời hạn sử dụng của nhiều phần mềm (thương mại / nội bộ) dài hơn nhiều so với tổ chức sản xuất chúng.

Vấn đề thường trở nên tồi tệ hơn bởi các dự án phần mềm dẫn đầu bộ phận tiếp thị sử dụng tên du jour mà họ sử dụng đề cập đến một dự án nhất định. Một cái tên sẽ, không thất bại, thay đổi 3 tháng xuống dòng để làm cho quần áo mới của hoàng đế cảm thấy tươi mới.

Vì điều này, tôi hầu như đã ngừng sử dụng tên miền ngược làm tên gói. Nếu được thực hiện trên quy mô lớn, sẽ có nguy cơ va chạm tên, nhưng chắc chắn điều này được giảm thiểu bằng cách sử dụng tên phần mềm "duy nhất", tránh các từ chung chung hoặc sử dụng tên miền ngược cho các dự án được bán / phát hành dưới dạng thư viện .

Những suy nghĩ khác?

Tôi sẽ trích dẫn lời khuyên mà Microsoft đưa ra cho các không gian tên (các gói của .NET), không có quy ước tên miền. Tôi nghĩ đó cũng là lời khuyên tốt cho các gói Java, vì tôi không tin rằng một tên miền đại diện cho một bản sắc vững chắc và ổn định.

Định dạng chung cho tên không gian tên như sau:

<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]

Ví dụ , Microsoft.WindowsMobile.DirectX.

Đặt tên không gian tên tiền tố với tên công ty để ngăn không gian tên từ các công ty khác nhau có cùng tên và tiền tố.

Sử dụng tên sản phẩm ổn định, độc lập với phiên bản ở cấp thứ hai của tên không gian tên.

Không sử dụng hệ thống phân cấp tổ chức làm cơ sở cho các tên trong hệ thống phân cấp không gian tên, vì tên nhóm trong các công ty có xu hướng tồn tại trong thời gian ngắn.

Tên không gian tên là một định danh tồn tại lâu dài và không thay đổi. Khi các tổ chức phát triển, các thay đổi sẽ không làm cho tên không gian tên bị lỗi thời.

Nếu ngay cả tên công ty của bạn không ổn định, bạn có thể muốn bắt đầu với tên sản phẩm.

Bạn đang xem xét giải pháp cho một vấn đề khác, cụ thể là làm thế nào để chúng ta tránh việc lập trình viên X và lập trình viên Y bước lên các ngón chân khác bằng cách đặt các tệp trong cùng một gói.

"Chỉ cần đảo ngược tên miền của bạn" giải quyết điều này một cách tao nhã, vì khi đó bạn khá chắc chắn rằng nếu X và Y không liên quan đến nhau, họ sẽ không chọn cùng một không gian tên gói.

Công ước không thiếu sót. Mọi người là thiếu sót, như bạn đã minh họa độc đáo chính mình.

Tôi có thể nghĩ về 2 lợi ích:

1. Nó tránh va chạm giữa các nhà phát triển độc lập. Một miền là duy nhất. Hai người có thể đặt tên cho hai dự án khác nhau giống nhau, nhưng một tên miền có chính xác một chủ sở hữu.
2. Nó làm cho nó dễ dàng hơn để tìm người bảo trì. Nếu bạn kế thừa một cơ sở mã, sử dụng một số thư viện nguồn mở, tốt hơn là trong một gói giúp bạn tìm thấy nó. Bây giờ nó không thực sự quan trọng, bởi vì bạn chắc chắn sẽ có thể google nó. Nhưng 10 năm trước, điều này không quá rõ ràng.

Tên miền ngược được sử dụng để tránh xung đột tên trong trường hợp các tổ chức khác nhau sử dụng cùng tên lớp trong thư viện của họ. Đó là một giải pháp đơn giản và tắt nguồn có một số nhược điểm (ví dụ như về xung đột tên cho các lớp trong cùng một tổ chức thì sao?).

Bạn không bắt buộc phải sử dụng nó, đó là một quy ước không phải là quy tắc làm hay chết. Ví dụ, một số lập trình viên Java không tôn trọng các Quy ước về Mã Java .

Nhưng hãy xem xét các lựa chọn thay thế. Ví dụ, làm thế nào bạn muốn hai tên lớp đủ điều kiện cho LogFactory:

a50e8400_e29b_41d4_a716_446655440000.LogFactory
f47ac10b_58cc_4372_a567_0e02b2c3d479.Logfactory

hoặc là

org.apache.commons.logging.LogFactory
com.evilcorp.logging.LogFactory

Vì vậy, theo suy nghĩ của tôi, hãy sử dụng bất cứ thứ gì bạn thích miễn là nó bao gồm ý thức chung và sự cân nhắc cho người dùng thư viện của bạn.

Khi tôi bắt đầu một dự án mới, tôi luôn nhấn mạnh vào một tên nội bộ và không thể thay đổi mà những người tiếp thị có thể biết hoặc không biết, vì nó sẽ chỉ được đề cập trong mã nguồn. Bằng cách đó, tôi không phải lo lắng về việc thay đổi tên dự án và ô nhiễm không gian tên.

Kịch bản này phù hợp với tôi, bởi vì mã nguồn thường không phải là một phần quan trọng của sản phẩm, tức là các dự án thường là một hệ thống độc quyền, nguồn đóng. Tuy nhiên, trong các dự án nguồn mở nơi mã nguồn là sản phẩm, điều này có thể không khả thi.