Quy ước đặt tên cho các lớp tiện ích trong Java

115

Khi viết các lớp tiện ích trong Java, một số hướng dẫn tốt cần tuân theo là gì?

Các gói có nên "dùng" hay "utils" không? Đó là ClassUtil hay ClassUtils? Khi nào một lớp là "Người trợ giúp" hay "Tiện ích"? Tiện ích hay Tiện ích? Hay bạn sử dụng hỗn hợp của chúng?

Thư viện Java tiêu chuẩn sử dụng cả Utils và Utilities:

javax.swing.Utilities
javax.print.attribute.AttributeSetUtilities
javax.swing.plaf.basic.BasicGraphicsUtils

Apache sử dụng nhiều loại Util và Utils, mặc dù chủ yếu là Utils:

org.apache.commons.modeler.util.DomUtil
org.apache.commons.modeler.util.IntrospectionUtils
org.apache.commons.io.FileSystemUtils
org.apache.lucene.wordnet.AnalyzerUtil
org.apache.lucene.util.ArrayUtil
org.apache.lucene.xmlparser.DOMUtils

Spring sử dụng rất nhiều lớp Helper và Utils:

org.springframework.web.util.UrlPathHelper
org.springframework.core.ReflectiveVisitorHelper
org.springframework.core.NestedExceptionUtils
org.springframework.util.NumberUtils

Vì vậy, làm thế nào để bạn đặt tên cho các lớp tiện ích của bạn?

java naming-conventions

— JR.
nguồn

82

Giống như nhiều quy ước khác, điều quan trọng không phải là bạn sử dụng quy ước nào mà là bạn sử dụng nó một cách nhất quán. Giống như, nếu bạn có ba lớp tiện ích và bạn gọi chúng là CustomerUtil, ProductUtils và StoreUtility, những người khác đang cố gắng sử dụng các lớp của bạn sẽ liên tục nhầm lẫn và gõ nhầm CustomerUtils, phải tra cứu, chửi rủa bạn vài lần, v.v. (Tôi đã nghe một bài giảng về tính nhất quán một lần trong đó người nói đưa ra một slide trình bày một dàn ý bài phát biểu của mình với ba điểm chính, được gắn nhãn "1", "2" và "C".)

Đừng bao giờ tạo ra hai cái tên chỉ khác nhau ở một số nét chính tả tinh vi, như có một CustomerUtil và một CustomerUtility. Nếu có một lý do chính đáng để tạo ra hai lớp, thì chắc chắn phải có điều gì đó khác biệt về chúng, và cái tên ít nhất phải cho chúng ta biết sự khác biệt đó là gì. Nếu một chứa các chức năng tiện ích liên quan đến tên và địa chỉ và chức năng kia chứa các chức năng tiện ích liên quan đến đơn đặt hàng, thì hãy gọi chúng là CustomerNameAndAddressUtil và CustomerOrderUtil hoặc một số như vậy. Tôi thường xuyên phát điên khi thấy những khác biệt nhỏ vô nghĩa trong tên gọi. Giống như mới hôm qua, tôi đã làm việc trên một chương trình có ba trường cho chi phí vận chuyển hàng hóa, có tên là "cước phí", "cước phí vận chuyển" và "frght". Tôi đã phải nghiên cứu mã để tìm ra sự khác biệt giữa chúng là gì.

— Jay
nguồn

9

Và IV cho số 4 :-) - Nhưng những gì là sự khác biệt giữa hàng hóa , freightcost , và frght ?

— KajMagnus

4

@KayMagnus Bài đăng đó cách đây hơn một năm, nhưng tôi nhớ lại, một trong số đó là chi phí vận chuyển hiện tại trên hồ sơ, trước khi thay đổi nội dung của đơn đặt hàng và do đó có khả năng là chi phí vận chuyển; khác là chi phí vận chuyển tiêu chuẩn được lấy từ một bảng; và thứ ba là chi phí tính toán được sử dụng trong một số trường hợp đặc biệt, như các chuyến hàng đi nước ngoài. Giống như tại sao ít nhất họ không thể gọi chúng, chẳng hạn như "currFreight", "stdFreight" và "calcFreight". Điều đó ít nhất sẽ cho một clude.

— Jay

Được rồi, cảm ơn cho lời giải thích :-) Một kỳ lạ mã thú Ví dụ: Tôi nghĩ rằng

— KajMagnus

31

Không có quy tắc / quy ước tiêu chuẩn trong thế giới Java cho điều này. Tuy nhiên, tôi thích thêm "s" vào cuối tên Lớp như @colinD đã đề cập.

Điều đó có vẻ khá chuẩn đối với những gì Nhà thiết kế API java bậc thầy Josh Bloch làm (bộ sưu tập java cũng như bộ sưu tập google)

Miễn là Helper và Util đi, tôi sẽ gọi một cái gì đó là Helper khi nó có các API giúp đạt được một chức năng cụ thể của một gói (coi một gói là triển khai một mô-đun); nghĩa là trong khi một Util có thể được gọi trong bất kỳ ngữ cảnh nào.

Ví dụ: trong một ứng dụng liên quan đến tài khoản ngân hàng, tất cả các API tĩnh của tiện ích cụ thể sẽ chuyển đến org.mycompany.util.Numbers

Tất cả các API trợ giúp quy tắc kinh doanh cụ thể cho "Tài khoản" sẽ chuyển đến

org.mycompany.account.AccountHelper

Rốt cuộc, vấn đề là cung cấp tài liệu tốt hơn và mã sạch hơn.

— người mang nhẫn
nguồn

5

Điều đó có vẻ hợp lý, Người trợ giúp đó sẽ nói rõ hơn về Utils đó.

— KajMagnus

1

Vâng, tôi thích cách tiếp cận này, nó hợp lý hơn.

— Conan

3

Liên kết bị hỏng. Tôi đã tìm thấy một cái khác .

— Chavjoh

22

Tôi thích quy ước chỉ thêm "s" vào tên kiểu khi kiểu là một giao diện hoặc một lớp mà bạn không kiểm soát. Ví dụ về điều đó trong JDK bao gồm Collectionsvà Executors. Đây cũng là quy ước được sử dụng trong Bộ sưu tập của Google.

Khi bạn đang xử lý một lớp mà bạn có quyền kiểm soát, tôi muốn nói rằng các phương thức tiện ích nói chung thuộc về chính lớp đó.

— ColinD
nguồn

2

Google Guava cũng sử dụng mẫu này

— Jherico

11

Tôi nghĩ rằng 'utils' phải là tên gói. Tên lớp phải chỉ rõ mục đích của logic bên trong nó. Thêm (các) sufix là thừa.

— Aito
nguồn

2

Đó sẽ không phải là điều đúng đắn để làm trong cách tiếp cận 'gói theo tính năng' .

— jpangamarca

1

@jpangamarca Tuy nhiên, bài viết bạn đã liên kết có một gói "dùng" trong ví dụ cho 'gói theo tính năng'. Tôi nghĩ rằng trong thực tế, một số loại tính năng / lớp tận dụng thường không thể tránh khỏi.

— kapex

1

@kapex Tôi đoán là một giám sát của tác giả. Một tld.organization.app.utilgói không nên tồn tại (có thể, nhưng không nên), bất kỳ số lượng tld.organization.app.feature.utilgói nào cũng hoàn toàn ổn.

— jpangamarca

3

Tôi khá chắc chắn rằng các từ "trợ giúp" và "tiện ích" được sử dụng thay thế cho nhau. Dù sao xét theo các ví dụ bạn đã cung cấp, tôi muốn nói nếu tên lớp của bạn là một chữ viết tắt (hoặc có các chữ viết tắt trong đó như "DomUtil") thì hãy gọi gói của bạn là "bất cứ điều gì.W AnythingUtil" (hoặc Utils nếu có nhiều tiện ích trong gói của bạn ). Nếu không, nếu nó có tên đầy đủ thay vì viết tắt, thì hãy gọi nó là "anything.W AnythingUtilities".

Điều đó thực sự tùy thuộc vào bạn, nhưng miễn là các lập trình viên biết bạn đang nói về điều gì, bạn có thể bắt đầu. Tuy nhiên, nếu bạn đang làm việc này một cách chuyên nghiệp như một công việc cho ai đó, hãy hỏi họ tiêu chuẩn mã hóa của họ là gì trước khi nghe lời khuyên của tôi. Luôn đi theo các tiêu chuẩn của cửa hàng cho dù thế nào đi nữa vì điều đó sẽ giúp bạn giữ được công việc của mình. :-)

— KSwift87
nguồn