adicionales - herramientas del java

Convención de nombres para clases de utilidad en Java (5)

Al igual que muchas de estas convenciones, lo importante no es tanto la convención que utilice, sino que la use de manera consistente. Por ejemplo, si tiene tres clases de utilidad y las llama CustomerUtil, ProductUtils y StoreUtility, las demás personas que intenten utilizar sus clases se confundirán constantemente y escribirán CustomerUtils por error, tendrán que buscarlo, maldecirlo un par de veces, etc. (Escuché una conferencia sobre consistencia una vez en la que el hablante colocó una diapositiva mostrando un esquema de su discurso con tres puntos principales, etiquetados "1", "2 °" y "C").

Nunca haga dos nombres que difieran solo en la sutileza de la ortografía, como tener una CustomerUtil y una CustomerUtility. Si había una buena razón para hacer dos clases, entonces debe haber algo diferente acerca de ellas, y el nombre debería al menos darnos una pista de la diferencia. Si uno contiene funciones de utilidad relacionadas con el nombre y la dirección y el otro contiene funciones de utilidad relacionadas con los pedidos, llámelos CustomerNameAndAddressUtil y CustomerOrderUtil o algo así. Regularmente me vuelvo loco cuando veo diferencias sutiles sin sentido en los nombres. Al igual que ayer, estaba trabajando en un programa que tenía tres campos para los costos de flete, llamados "flete", "flete" y "frght". Tuve que estudiar el código para descubrir cuál era la diferencia entre ellos.

Al escribir clases de utilidad en Java, ¿cuáles son algunas buenas pautas a seguir?

¿Los paquetes deben ser "util" o "utils"? ¿Es ClassUtil o ClassUtils? ¿Cuándo es una clase un "Ayudante" o una "Utilidad"? ¿Utilidad o utilidades? ¿O usas una mezcla de ellos?

La biblioteca estándar de Java usa tanto utilidades como utilidades:

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

Apache usa una variedad de Util y Utils, aunque principalmente 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 usa muchas clases de Helper y Utils:

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

Entonces, ¿cómo nombras tus clases de utilidad?

Creo que ''utils'' debería ser el nombre del paquete. Los nombres de clase deben especificar el propósito de la lógica dentro de él. Agregar el sufijo -util (s) es redundante.

Estoy bastante seguro de que las palabras "ayudantes" y "utilidades" se usan indistintamente. De todos modos, a juzgar por los ejemplos que proporcionaste, diría que si tu nombre de clase es una abreviatura (o tiene abreviaturas como "DomUtil"), llama a tu paquete "whatever.WhateverUtil" (o Utils si hay más de una utilidad en tu paquete) ) De lo contrario, si tiene un nombre completo en lugar de una abreviatura, llámalo "whatever.WhateverUtilities".

Depende de ti, pero mientras los programadores sepan de lo que estás hablando, estarás listo. Si estás haciendo esto profesionalmente como un trabajo para alguien, pregúntales cuáles son sus estándares de codificación antes de seguir mi consejo. Siempre respete los estándares de la tienda, sin importar qué, ya que eso lo ayudará a mantener su trabajo. :-)

Me gusta la convención de simplemente agregar "s" al nombre del tipo cuando el tipo es una interfaz o una clase que no controlas. Ejemplos de eso en el JDK incluyen Collections y Executors . También es la convención utilizada en Google Collections.

Cuando se trata de una clase sobre la que se tiene control, yo diría que los métodos de utilidad pertenecen a la clase en general.

No hay una regla / convención estándar en el mundo de Java para esto. Sin embargo, prefiero agregar "s" al final del nombre de la Clase como lo ha mencionado @colinD.

Eso parece bastante estándar para lo que hace el diseñador de la API de Master Java Josh Bloch (colección de Java y colección de Google)

Mientras Helper and Util vaya, voy a llamar a algo como un Helper cuando tiene API que ayudan a lograr una funcionalidad específica de un paquete (considerando un paquete como para implementar un módulo); significa que se puede llamar a un Util en cualquier contexto.

Por ejemplo, en una aplicación relacionada con cuentas bancarias, todas las API estáticas de servicios específicos de números irían a org.mycompany.util.Numbers

Todas las reglas comerciales específicas de "Cuenta" que ayudan a las API irían a

org.mycompany.account.AccountHelper

Después de todo, se trata de proporcionar una mejor documentación y un código más limpio.