2010-04-20 30 views
90

Khi viết các lớp tiện ích trong Java, một số nguyên tắc tốt để làm theo là gì?Quy ước đặt tên cho các lớp tiện ích trong Java

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

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

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

Apache sử dụng nhiều 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?

Trả lời

60

Giống như nhiều quy ước như vậy, điều quan trọng không phải là quá nhiều quy ước bạn sử dụng, vì 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 học của bạn sẽ liên tục bị lẫn lộn và gõ CustomerUtils do nhầm lẫn, phải tra cứu, nguyền rủa bạn vài lần, vv (Tôi nghe một bài giảng về tính nhất quán một lần khi người thuyết trình đưa ra một bản trình bày bản phác thảo bài phát biểu của mình với ba điểm chính, có nhãn "1", "2nd" và "C".)

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

+7

Và IV cho số 4 :-) - Nhưng cái gì * là * sự khác biệt giữa * vận chuyển hàng hóa *, * freightcost * và * frght *? – KajMagnus

+3

@KayMagnus Bài đăng đó đã hơn một năm trước, nhưng khi 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 chi phí vận tải; khác là chi phí vận chuyển hàng hóa tiêu chuẩn được lấy từ một bảng; và thứ ba là chi phí được tính toán được sử dụng trong một số trường hợp đặc biệt, như các lô hàng ở nước ngoài. Giống như lý do tại sao họ không thể ít nhất đã gọi cho họ, nói, "currFreight", "stdFreight", và "calcFreight". Điều đó ít nhất cũng đã đưa ra một lời nói dối. – Jay

+0

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

8

Tôi nghĩ rằng 'utils' phải là tên gói. Các tên lớp nên xác định mục đích của logic bên trong nó. Thêm sufix -util (s) là dư thừa.

+1

Điều đó sẽ không đúng khi thực hiện theo cách tiếp cận ['gói theo tính năng'] (http://www.javapractices.com/topic/TopicAction.do?Id=205). – jpangamarca

3

Tôi khá chắc chắn rằng từ "người trợ giúp" và "tiện ích" được sử dụng thay thế cho nhau. Dù sao đánh giá bằng các ví dụ bạn cung cấp, tôi sẽ nói nếu tên lớp của bạn là viết tắt (hoặc có chữ viết tắt trong nó như "DomUtil"), sau đó gọi gói của bạn "whatever.WhateverUtil" (hoặc Utils nếu có nhiều hơn một tiện ích trong gói của bạn). Khác nếu nó có một tên đầy đủ thay vì viết tắt, sau đó gọi nó là "whatever.WhateverUtilities".

Điều đó thực sự tùy thuộc vào bạn, nhưng miễn là người lập trình biết bạn đang nói về điều gì, bạn thật dễ dàng. 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ọ những tiêu chuẩn mã hóa của họ trước khi thực hiện lời khuyên của tôi. Luôn luôn đi với các tiêu chuẩn cửa hàng không có vấn đề gì như vậy sẽ giúp bạn giữ công việc của bạn. :-)

18

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

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

+2

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

23

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

Điều đó có vẻ khá chuẩn với những gì Master java API Designer Josh Bloch does (bộ sưu tập java cũng như google bộ sưu tập)

Chừng nào Helper và util đi, tôi sẽ gọi cho một cái gì đó một Helper khi nó có API giúp để đạt được một chức năng cụ thể của một gói (xem xét một gói để thực hiện một mô-đun); có nghĩa là trong khi 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 các tài khoản ngân hàng, tất cả số tiện ích cụ thể API tĩnh sẽ đi đến org.mycompany.util.Numbers

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

org.mycompany.account.AccountHelper 

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

+4

Điều đó có vẻ hợp lý, mà Helper sẽ cụ thể hơn là Utils. – KajMagnus

+0

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

+0

Liên kết bị hỏng. Tôi đã tìm thấy [một số khác] (http://www.cs.bc.edu/~muller/teaching/cs102/s06/lib/pdf/api-design). – Chavjoh

Các vấn đề liên quan