Konvensi penamaan untuk kelas utilitas di Java

115

Saat menulis kelas utilitas di Java, apa sajakah pedoman yang baik untuk diikuti?

Haruskah paket menjadi "util" atau "utils"? Apakah ClassUtil atau ClassUtils? Kapan kelas menjadi "Helper" atau "Utility"? Utilitas atau Utilitas? Atau apakah Anda menggunakan campurannya?

Pustaka Java standar menggunakan Utils dan Utilities:

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

Apache menggunakan berbagai Util dan Utils, meskipun kebanyakan 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 menggunakan banyak class Helper dan Utils:

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

Jadi, bagaimana Anda memberi nama kelas utilitas Anda?

java naming-conventions JR.
sumber

Jawaban:

82

Seperti banyak konvensi semacam itu, yang penting bukanlah konvensi apa yang Anda gunakan, melainkan yang Anda gunakan secara konsisten. Seperti, jika Anda memiliki tiga kelas utilitas dan Anda menyebutnya CustomerUtil, ProductUtils, dan StoreUtility, orang lain yang mencoba menggunakan kelas Anda akan terus-menerus bingung dan mengetik CustomerUtils karena kesalahan, harus mencarinya, mengutuk Anda beberapa kali, dll. (Saya pernah mendengar kuliah tentang konsistensi di mana pembicara memasang slide yang menunjukkan garis besar pidatonya dengan tiga poin utama, berlabel "1", "2nd", dan "C".)

Jangan pernah membuat dua nama yang berbeda hanya dalam beberapa kehalusan ejaan, seperti memiliki CustomerUtil dan CustomerUtility. Jika ada alasan bagus untuk membuat dua kelas, maka pasti ada sesuatu yang berbeda tentang mereka, dan nama setidaknya harus memberi kita petunjuk tentang perbedaan itu. Jika satu berisi fungsi utilitas yang terkait dengan nama dan alamat dan yang lainnya berisi fungsi utilitas yang terkait dengan pesanan, maka panggil mereka CustomerNameAndAddressUtil dan CustomerOrderUtil atau semacamnya. Saya sering menjadi gila ketika melihat perbedaan nama yang tidak kentara. Seperti baru kemarin saya mengerjakan sebuah program yang memiliki tiga bidang untuk biaya pengiriman, bernama "kargo", "biaya pengiriman", dan "frght". Saya harus mempelajari kodenya untuk mencari tahu apa perbedaan di antara mereka.

Jay
sumber
9
Dan IV untuk nomor 4 :-) - Tapi apa itu perbedaan antara barang , freightcost , dan frght ?
KajMagnus
4
@KayMagnus Posting itu sudah lebih dari setahun yang lalu, tapi seingat saya, salah satunya adalah biaya pengiriman saat ini yang tercatat, sebelum mengubah isi pesanan dan dengan demikian berpotensi menjadi biaya pengiriman; lainnya adalah biaya pengangkutan standar yang diambil dari tabel; dan yang ketiga adalah biaya kalkulasi yang digunakan dalam beberapa kasus khusus, seperti pengiriman ke luar negeri. Seperti mengapa mereka tidak bisa setidaknya memanggil mereka, katakanlah, "currFreight", "stdFreight", dan "calcFreight". Itu setidaknya akan memberikan clude.
Jay
Oke, terima kasih atas penjelasannya :-) Contoh kode aneh yang menarik menurut saya
KajMagnus
31

Tidak ada aturan / konvensi standar di dunia Java untuk ini. Namun, saya lebih suka menambahkan "s" di akhir nama Kelas seperti yang disebutkan @colinD.

Itu tampaknya cukup standar untuk apa yang dilakukan oleh Master java API Designer Josh Bloch (koleksi java serta koleksi google)

Selama Helper dan Util berjalan, saya akan memanggil sesuatu sebagai Helper ketika memiliki API yang membantu mencapai fungsionalitas tertentu dari sebuah paket (mempertimbangkan sebuah paket untuk mengimplementasikan modul); berarti sementara Util dapat dipanggil dalam konteks apa pun.

Misalnya dalam aplikasi yang terkait dengan rekening bank, semua API statis utilitas nomor tertentu akan pergi ke org.mycompany.util.Numbers

Semua API yang membantu aturan bisnis khusus "Akun" akan masuk

org.mycompany.account.AccountHelper

Bagaimanapun, ini adalah masalah menyediakan dokumentasi yang lebih baik dan kode yang lebih bersih.

Pembawa cincin
sumber
5
Tampaknya masuk akal, bahwa Pembantu akan lebih spesifik daripada Utils.
KajMagnus
1
Ya, saya suka pendekatan ini, ini lebih logis.
Conan
3
Tautannya rusak. Saya menemukan satu sama lain .
Chavjoh
22

Saya suka konvensi hanya menambahkan "s" ke nama tipe ketika tipenya adalah antarmuka atau kelas yang tidak Anda kontrol. Contohnya di JDK termasuk Collectionsdan Executors. Itu juga konvensi yang digunakan di Google Collections.

Ketika Anda berurusan dengan kelas yang Anda kendalikan, saya akan mengatakan metode utilitas termasuk dalam kelas itu sendiri secara umum.

ColinD
sumber
2
Google Guava juga menggunakan pola ini
Jherico
11

Saya pikir 'utils' harus menjadi nama paket. Nama kelas harus menentukan tujuan logika di dalamnya. Menambahkan sufix -util (s) adalah redundan.

Aito
sumber
2
Itu bukanlah hal yang benar untuk dilakukan dalam pendekatan 'paket demi fitur' .
jpangamarca
1
@jpangamarca Artikel yang Anda tautkan memiliki paket "util" dalam contoh untuk 'paket demi fitur'. Menurut saya dalam praktiknya beberapa jenis fitur / lapisan util sering kali tidak dapat dihindari.
kapex
1
@kapex Kelalaian dari penulis saya kira. Sebuah tld.organization.app.utilpaket tidak boleh ada (bisa, tetapi tidak boleh), sejumlah tld.organization.app.feature.utilpaket baik-baik saja.
jpangamarca
3

Saya cukup yakin kata "pembantu" dan "utilitas" digunakan secara bergantian. Bagaimanapun menilai dari contoh yang Anda berikan, saya akan mengatakan jika nama kelas Anda adalah singkatan (atau memiliki singkatan di dalamnya seperti "DomUtil") kemudian panggil paket Anda "terserah.WhateverUtil" (atau Utils jika ada lebih dari satu utilitas dalam paket Anda ). Lain jika itu memiliki nama lengkap dan bukan singkatan, maka sebut saja "terserah.WhateverUtilities".

Ini benar-benar terserah Anda, tetapi selama pembuat kode tahu apa yang Anda bicarakan, Anda siap melakukannya. Jika Anda melakukan ini secara profesional sebagai pekerjaan untuk seseorang, tanyakan kepada mereka apa standar pengkodean mereka sebelum menerima saran saya. Selalu ikuti standar toko tidak peduli apa yang akan membantu Anda mempertahankan pekerjaan Anda. :-)

KSwift87
sumber