หลักการตั้งชื่อสำหรับคลาสยูทิลิตี้ใน Java

116

เมื่อเขียนคลาสยูทิลิตี้ใน Java ควรปฏิบัติตามแนวทางใดบ้าง

แพ็กเกจควรเป็น "util" หรือ "utils"? มันคือ ClassUtil หรือ ClassUtils? ชั้นเรียนเป็น "ตัวช่วย" หรือ "ยูทิลิตี้" เมื่อใด ยูทิลิตี้หรือยูทิลิตี้? หรือคุณใช้ส่วนผสมของมัน?

ไลบรารี Java มาตรฐานใช้ทั้ง Utils และ Utilities:

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

Apache ใช้ Util และ Utils ที่หลากหลายแม้ว่า 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 ใช้คลาส Helper และ Utils มากมาย:

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

คุณตั้งชื่อคลาสยูทิลิตี้ของคุณได้อย่างไร?

java naming-conventions

— จูเนียร์
แหล่งที่มา

83

เช่นเดียวกับอนุสัญญาดังกล่าวสิ่งที่สำคัญไม่ใช่สิ่งที่คุณใช้ในการประชุมมากเท่าที่คุณใช้อย่างสม่ำเสมอ เช่นถ้าคุณมีคลาสยูทิลิตี้สามคลาสและเรียกพวกเขาว่า CustomerUtil, ProductUtils และ StoreUtility คนอื่น ๆ ที่พยายามใช้คลาสของคุณจะสับสนอยู่ตลอดเวลาและพิมพ์ CustomerUtils โดยไม่ได้ตั้งใจต้องค้นหามันด่าคุณสองสามครั้ง ฯลฯ (ฉันได้ยินการบรรยายเกี่ยวกับความสอดคล้องครั้งหนึ่งที่ผู้พูดวางสไลด์แสดงโครงร่างคำพูดของเขาโดยมีประเด็นหลัก 3 ประเด็นคือ "1", "2" และ "C")

ไม่เคยสร้างชื่อสองชื่อที่แตกต่างกันในความละเอียดอ่อนของการสะกดเช่นการมี CustomerUtil และ CustomerUtility หากมีเหตุผลที่ดีในการสร้างสองคลาสก็ต้องมีบางอย่างที่แตกต่างกันเกี่ยวกับพวกเขาและอย่างน้อยชื่อก็ควรให้เบาะแสว่าแตกต่างกันอย่างไร หากมีฟังก์ชันยูทิลิตี้ที่เกี่ยวข้องกับชื่อและที่อยู่และอีกฟังก์ชันหนึ่งมีฟังก์ชันยูทิลิตี้ที่เกี่ยวข้องกับคำสั่งซื้อให้เรียกพวกเขาว่า CustomerNameAndAddressUtil และ CustomerOrderUtil หรือบางอย่าง ฉันหมั่นไส้เป็นประจำเมื่อเห็นความแตกต่างที่ไม่มีความหมายในชื่อ เช่นเดียวกับเมื่อวานนี้ฉันกำลังทำงานในโปรแกรมที่มีช่องสำหรับค่าขนส่งสามช่องชื่อ "ค่าขนส่ง" "ค่าขนส่ง" และ "frght" ฉันต้องศึกษารหัสเพื่อดูว่าความแตกต่างระหว่างรหัสนั้นคืออะไร

— คนโง่
แหล่งที่มา

9

และ IV จำนวน 4 :-) - แต่สิ่งที่เป็นความแตกต่างระหว่างการขนส่งสินค้า , freightcostและfrght ?

— KajMagnus

4

@KayMagnus โพสต์นั้นเมื่อปีที่แล้ว แต่อย่างที่ฉันจำได้หนึ่งในนั้นคือต้นทุนการขนส่งสินค้าปัจจุบันในบันทึกก่อนที่จะเปลี่ยนเนื้อหาของคำสั่งซื้อและอาจเป็นค่าขนส่ง อีกประการหนึ่งคือค่าขนส่งมาตรฐานที่นำมาจากตาราง และอย่างที่สามคือต้นทุนที่คำนวณได้ซึ่งใช้ในกรณีพิเศษบางอย่างเช่นการจัดส่งไปต่างประเทศ เช่นเดียวกับที่ทำไมอย่างน้อยถึงเรียกพวกเขาไม่ได้พูดว่า "currFreight" "stdFreight" และ "calcFreight" อย่างน้อยก็จะให้ความรู้สึกไม่สบายใจ

— เจย์

โอเคขอบคุณสำหรับคำอธิบาย :-) ตัวอย่างรหัสแปลก ๆ ที่น่าสนใจที่ฉันคิด

— KajMagnus

31

ไม่มีกฎ / อนุสัญญามาตรฐานในโลก Java สำหรับสิ่งนี้ อย่างไรก็ตามฉันชอบเพิ่ม "s" ต่อท้ายชื่อคลาสตามที่ @colinD ได้กล่าวไว้

ดูเหมือนจะค่อนข้างเป็นมาตรฐานสำหรับสิ่งที่Master java API Designer Josh Bloch ทำ (คอลเลกชัน java และคอลเลคชันของ Google)

ตราบใดที่ Helper และ Util ดำเนินไปฉันจะเรียกสิ่งที่เรียกว่า Helper เมื่อมี API ที่ช่วยในการทำงานเฉพาะของแพ็กเกจ (โดยพิจารณาจากแพ็คเกจเพื่อใช้โมดูล) หมายถึงในขณะที่ Util อาจถูกเรียกในบริบทใด ๆ

ตัวอย่างเช่นในแอปพลิเคชันที่เกี่ยวข้องกับบัญชีธนาคาร API คงที่ของยูทิลิตี้เฉพาะจำนวนทั้งหมดจะไปที่ org.mycompany.util.Numbers

กฎทางธุรกิจเฉพาะสำหรับ "บัญชี" ที่ช่วย API ทั้งหมดจะไปที่

org.mycompany.account.AccountHelper

ท้ายที่สุดมันเป็นเรื่องของการจัดเตรียมเอกสารที่ดีขึ้นและรหัสที่สะอาดกว่า

— ผู้ถือแหวน
แหล่งที่มา

5

ดูเหมือนจะสมเหตุสมผลผู้ช่วยจะเจาะจงมากขึ้นว่า Utils

— KajMagnus

1

ใช่ฉันชอบแนวทางนี้มันมีเหตุผลมากกว่า

— โคนัน

3

ลิงค์เสีย ผมพบว่าอีกคนหนึ่ง

— Chavjoh

22

ฉันชอบหลักการเพิ่ม "s" ให้กับชื่อประเภทเมื่อประเภทเป็นอินเทอร์เฟซหรือคลาสที่คุณไม่ได้ควบคุม ตัวอย่างที่อยู่ใน JDK รวมและCollections Executorsนอกจากนี้ยังเป็นการประชุมที่ใช้ใน Google Collections

เมื่อคุณจัดการกับคลาสที่คุณสามารถควบคุมได้ฉันจะบอกว่าวิธีการยูทิลิตี้นั้นอยู่ในคลาสนั้นเอง

— ColinD
แหล่งที่มา

2

Google Guava ก็ใช้รูปแบบนี้เช่นกัน

— Jherico

11

ฉันคิดว่า "utils" ควรเป็นชื่อแพ็คเกจ ชื่อคลาสควรระบุวัตถุประสงค์ของตรรกะภายใน การเพิ่ม sufix -util (s) ซ้ำซ้อน

— Aito
แหล่งที่มา

2

ไม่ว่าจะเป็นสิ่งที่ถูกต้องที่จะทำในแพคเกจโดยคุณลักษณะ 'วิธีการ

— jpangamarca

1

@jpangamarca บทความที่คุณเชื่อมโยงมีแพ็คเกจ "util" ในตัวอย่างสำหรับ "package by feature" ฉันคิดว่าในทางปฏิบัติคุณลักษณะ / เลเยอร์การใช้งานบางประเภทมักไม่สามารถหลีกเลี่ยงได้

— kapex

1

@kapex การกำกับดูแลจากผู้เขียนฉันเดา tld.organization.app.utilไม่ควรมีแพ็กเกจ (ทำได้ แต่ไม่ควร) จำนวนtld.organization.app.feature.utilแพ็กเกจใด ๆก็สมบูรณ์ดี

— jpangamarca

3

ฉันค่อนข้างมั่นใจว่าคำว่า "ตัวช่วย" และ "ยูทิลิตี้" ใช้แทนกันได้ อย่างไรก็ตามเมื่อพิจารณาจากตัวอย่างที่คุณให้มาฉันจะบอกได้ว่าชื่อคลาสของคุณเป็นตัวย่อ (หรือมีตัวย่อเช่น "DomUtil") ให้เรียกแพ็กเกจของคุณว่า "อะไรก็ได้ WhateverUtil" (หรือ Utils หากมีมากกว่าหนึ่งยูทิลิตี้ในแพ็คเกจของคุณ ) ไม่เช่นนั้นหากมีชื่อเต็มแทนตัวย่อให้เรียกว่า "อะไรก็ได้ WhateverUtilities"

มันขึ้นอยู่กับคุณจริงๆ แต่ตราบใดที่ผู้เขียนโค้ดรู้ว่าคุณกำลังพูดถึงอะไรคุณก็พร้อมที่จะไป หากคุณกำลังทำสิ่งนี้อย่างมืออาชีพในฐานะงานสำหรับใครบางคนให้ถามพวกเขาว่ามาตรฐานการเข้ารหัสของพวกเขาคืออะไรก่อนที่จะรับคำแนะนำของฉัน เป็นไปตามมาตรฐานร้านค้าเสมอไม่ว่าสิ่งนั้นจะช่วยให้คุณรักษางานของคุณได้ :-)

— KSwift87
แหล่งที่มา