Convención de nomenclatura para clases de servicios públicos en Java

115

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

¿Deben ser los paquetes "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 utiliza utilidades y 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 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 servicios públicos?

java naming-conventions JR.
fuente

Respuestas:

82

Como muchas de estas convenciones, lo importante no es tanto la convención que utilice, sino que la utilice de forma coherente. Por ejemplo, si tiene tres clases de servicios públicos y las llama CustomerUtil, ProductUtils y StoreUtility, otras personas que intenten usar sus clases se confundirán constantemente y escribirán CustomerUtils por error, tendrán que buscarlo, maldecirlo algunas veces, etc. (Una vez escuché una conferencia sobre la coherencia en la que el orador colocó una diapositiva que mostraba un esquema de su discurso con tres puntos principales, etiquetados como "1", "2nd" y "C").

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

Arrendajo
fuente
9
Y IV para el número 4 :-) - Pero, ¿cuál era la diferencia entre flete , flete costo y flete ?
KajMagnus
4
@KayMagnus Esa publicación fue hace más de un año, pero según recuerdo, uno de ellos fue el costo de flete actual en el registro, antes de cambiar el contenido del pedido y, por lo tanto, potencialmente el costo de flete; otro fue el costo de flete estándar tomado de una mesa; y el tercero fue un costo calculado utilizado en algunos casos especiales, como los envíos al extranjero. Como por qué no podían al menos haberlos llamado, digamos, "currFreight", "stdFreight" y "calcFreight". Eso al menos habría dado una pista.
Jay
Bien, gracias por la explicación :-) Un ejemplo interesante de código extraño, creo
KajMagnus
31

No existe 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 ha mencionado @colinD.

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

Mientras Helper y Util vayan, llamaré a algo Helper cuando tenga API que ayuden a lograr una funcionalidad específica de un paquete (considerando un paquete como para implementar un módulo); es decir, mientras que una Util se puede llamar en cualquier contexto.

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

Todas las API de ayuda de reglas de negocio específicas de "Cuenta" 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.

portador del anillo
fuente
5
Eso parece razonable, ese Helper sería más específico que Utils.
KajMagnus
1
Sí, me gusta este enfoque, es más lógico.
Conan
3
El vínculo está roto. Encontré otro .
Chavjoh
22

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 Collectionsy Executors. También es la convención utilizada en las colecciones de Google.

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

ColinD
fuente
2
Google Guava también usa este patrón
Jherico
11

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

Aito
fuente
2
Eso no sería lo correcto en un enfoque de "paquete por función" .
jpangamarca
1
@jpangamarca Sin embargo, el artículo que vinculó tiene un paquete "util" en el ejemplo de 'paquete por característica'. Creo que, en la práctica, a menudo no se puede evitar algún tipo de capa / característica útil.
kapex
1
@kapex Supongo que es un descuido del autor. Un tld.organization.app.utilpaquete no debería existir (podría, pero no debería), cualquier número de tld.organization.app.feature.utilpaquetes está perfectamente bien.
jpangamarca
3

Estoy bastante seguro de que las palabras "ayudantes" y "utilidades" se usan indistintamente. De todos modos, a juzgar por los ejemplos que proporcionó, diría que si su nombre de clase es una abreviatura (o tiene abreviaturas como "DomUtil"), llame a su paquete "lo que sea.WhateverUtil" (o Utils si hay más de una utilidad en su paquete ). De lo contrario, si tiene un nombre completo en lugar de una abreviatura, llámelo "cualquiera. Cualquiera que sea la utilidad".

Realmente depende de usted, pero mientras los programadores sepan de lo que está hablando, está listo para comenzar. Sin embargo, si está haciendo esto profesionalmente como un trabajo para alguien, pregúntele cuáles son sus estándares de codificación antes de seguir mi consejo. Siga siempre los estándares del taller, pase lo que pase, ya que eso le ayudará a mantener su trabajo. :-)

KSwift87
fuente