Namenskonvention für Utility-Klassen in Java

Was sind einige gute Richtlinien, die Sie beim Schreiben von Hilfsklassen in Java befolgen sollten?

Sollten Pakete “util” oder “utils” sein? Ist es ClassUtil oder ClassUtils? Wann ist eine Klasse ein „Helper“ oder ein „Utility“? Dienstprogramm oder Dienstprogramme? Oder verwendest du eine Mischung daraus?

Die Standard-Java-Bibliothek verwendet sowohl Utils als auch Utilities:

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

Apache verwendet eine Vielzahl von Utils und Utils, obwohl meistens 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 verwendet viele Helper- und Utils-Klassen:

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

Wie benennen Sie also Ihre Utility-Klassen?

Wie bei vielen solchen Konventionen ist nicht so sehr wichtig, welche Konvention Sie verwenden, sondern dass Sie sie konsistent verwenden. Wenn Sie beispielsweise drei Dienstprogrammklassen haben und diese CustomerUtil, ProductUtils und StoreUtility nennen, werden andere Leute, die versuchen, Ihre Klassen zu verwenden, ständig verwirrt sein und versehentlich CustomerUtils eingeben, müssen es nachschlagen und Sie ein paar Mal verfluchen. usw. (Ich habe einmal einen Vortrag über Konsistenz gehört, in dem der Redner eine Folie aufgehängt hat, die einen Überblick über seine Rede mit drei Hauptpunkten zeigt, die mit “1”, “2nd” und “C” bezeichnet sind.)

Machen Sie niemals zwei Namen, die sich nur in einer subtilen Schreibweise unterscheiden, wie z. B. ein CustomerUtil und ein CustomerUtility. Wenn es einen guten Grund gab, zwei Klassen zu machen, dann müssen sie etwas anderes sein, und der Name sollte uns zumindest einen Hinweis darauf geben, was dieser Unterschied ist. Wenn eine Utility-Funktionen in Bezug auf Name und Adresse und die andere Utility-Funktionen in Bezug auf Bestellungen enthält, dann nennen Sie sie CustomerNameAndAddressUtil und CustomerOrderUtil oder etwas Ähnliches. Ich werde regelmäßig verrückt, wenn ich bedeutungslose subtile Unterschiede in Namen sehe. Wie gerade gestern arbeitete ich an einem Programm, das drei Felder für Frachtkosten hatte, nämlich “freight”, “freightcost” und “frght”. Ich musste den Code studieren, um herauszufinden, was der Unterschied zwischen ihnen war.

Dafür gibt es in der Java-Welt keine Standardregel/-konvention. Ich bevorzuge jedoch das Hinzufügen von “s” am Ende des Klassennamens, wie @colinD erwähnt hat.

Das scheint ziemlich Standard zu sein Master Java API Designer Josh Bloch tut es (Java-Sammlung sowie Google-Sammlung)

Solange es Helper und Util gibt, werde ich etwas Helper nennen, wenn es APIs hat, die helfen, eine bestimmte Funktionalität eines Pakets zu erreichen (wenn man bedenkt, dass ein Paket ein Modul implementiert); bedeuten, während ein Util in jedem Kontext aufgerufen werden kann.

Beispielsweise würden in einer Anwendung, die sich auf Bankkonten bezieht, alle nummernspezifischen statischen APIs von Versorgungsunternehmen zu gehen org.mycompany.util.Numbers

Alle “Konto”-spezifischen Geschäftsregeln, die APIs unterstützen, gehen an

org.mycompany.account.AccountHelper

Schließlich geht es um bessere Dokumentation und saubereren Code.

Ich mag die Konvention, einfach ein “s” zum Typnamen hinzuzufügen, wenn der Typ eine Schnittstelle oder eine Klasse ist, die Sie nicht kontrollieren. Beispiele dafür im JDK umfassen Collections und Executors. Es ist auch die Konvention, die in Google Collections verwendet wird.

Wenn Sie es mit a zu tun haben Klasse Sie haben die Kontrolle über, ich würde sagen, Utility-Methoden gehören im Allgemeinen zur Klasse selbst.

Ich denke, dass ‘utils’ der Paketname sein sollte. Die Klassennamen sollten den Zweck der darin enthaltenen Logik angeben. Das Hinzufügen des Suffix -util(s) ist überflüssig.

Ich bin mir ziemlich sicher, dass die Wörter “Helfer” und “Dienstprogramme” synonym verwendet werden. Wie auch immer, nach den von Ihnen bereitgestellten Beispielen zu urteilen, würde ich sagen, wenn Ihr Klassenname eine Abkürzung ist (oder Abkürzungen wie “DomUtil” enthält), dann nennen Sie Ihr Paket “whatever.WhateverUtil” (oder Utils, wenn es mehr als ein Dienstprogramm in Ihrem Paket gibt ). Andernfalls, wenn es einen vollständigen Namen anstelle einer Abkürzung hat, nennen Sie es “whatever.WhateverUtilities”.

Es liegt wirklich an Ihnen, aber solange die Programmierer wissen, wovon Sie sprechen, können Sie loslegen. Wenn Sie dies jedoch beruflich als Job für jemanden machen, fragen Sie ihn nach seinen Programmierstandards, bevor Sie meinen Rat annehmen. Halten Sie sich immer an die Geschäftsstandards, egal was passiert, da dies Ihnen hilft, Ihren Job zu behalten. 🙂

Hier ist, was ich tue:

Ich betrachte Utility-Klassen als Code-Geruch, aber manchmal müssen sie Methoden wiederverwenden, die in keine andere Klasse passen.

Ich bevorzuge Dateinamen mit Utils Da es verschiedene Funktionen für mehrere Anwendungsfälle enthält, erstelle ich niemals ein Paket namens utils; Stattdessen platziere ich meine utils-Datei in dem am besten geeigneten vorhandenen Paket dafür.

Wenn ich zum Beispiel utils für ein Feature benötige, dann platziere ich die MyFeatureUtils.java Datei innerhalb der com.myapp.myfeature Paket.

Wenn ich kein geeignetes Paket für die utils-Datei habe oder von mehreren Modulen aus darauf zugreifen muss, platziere ich es in der root oder hinein common Paket.

Falls vorhanden utils package im Projekt, erst dann platziere ich die utils-Klasse darin.

Einige weitere Beispiele:

• com.myapp.notification.NotificationUtils.java
• com.myapp.account.AccountUtils.java
• com.myapp.data.DatabaseUtils.java
• com.myapp.view.ImageUtils.java
• com.myapp.analytics.LogUtils.java
• src/routes/route-utils.js
• src/middleware/auth-utils.js

PS: Ich verwende Helper nicht anstelle von Utils, da Helper zustandsbehaftet sein können und im Allgemeinen innerhalb einer Instanz zum Delegieren einiger Zustände und Aufgaben verwendet werden; während utils völlig zustandslos sind und nur statische Funktionen enthalten sollten.

PS: Ich verwende nicht Manager anstelle von Utils, da Manager zustandsbehaftet sein und verwendet werden können, um eine oder mehrere Instanzen bereitzustellen, zu verwalten und zu speichern.