2010-04-20 11 views
90

Al escribir clases de utilidad en Java, ¿cuáles son algunas buenas pautas a seguir?Convención de nomenclatura para clases de utilidad en Java

¿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 utiliza tanto Utilidades y utilidades:

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

Apache utiliza una variedad de Util y Utils, aunque en su mayoría 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

primavera utiliza una gran cantidad de clases auxiliares y Utilidades de:

  • 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?

Respuesta

60

Al igual que 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 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 donde el orador mostró una diapositiva mostrando un resumen de su discurso con tres puntos principales, etiquetados "1", "2 °" y "C").

Nunca jamás haga dos nombres que difieran solo en algunas sutilezas de 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.

+7

Y IV para el número 4 :-) - ¿Pero qué * era * la diferencia entre * freight *, * freightcost * y * frght *? – KajMagnus

+3

@KayMagnus Esa publicación fue hace más de un año, pero según recuerdo, una de ellas era el costo actual del flete registrado, antes de cambiar el contenido del pedido y, por lo tanto, potencialmente el costo del flete; otro fue el costo de flete estándar tomado de una mesa; y el tercero era un costo calculado utilizado en algunos casos especiales, como los envíos al exterior. Al igual que por qué no podrían al menos haberlos llamado, por ejemplo, "currFreight", "stdFreight" y "calcFreight". Eso al menos habría dado una clueda. – Jay

+0

Bien, gracias por la explicación :-) Un ejemplo interesante de código extraño Creo que – KajMagnus

8

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.

+1

Eso no sería lo correcto en un enfoque ['paquete por función'] (http://www.javapractices.com/topic/TopicAction.do?Id=205). – jpangamarca

3

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, está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. :-)

18

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 que tiene el control, yo diría que los métodos de utilidad pertenecen a la clase en general.

+2

Google Guava también usa este patrón – Jherico

23

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

Eso parece bastante estándar a lo Master java API Designer Josh Bloch does (colección de Java, así como la recopilación de Google)

Mientras va ayudante y Util, voy a llamar a algo un ayudante cuando tiene APIs 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 las cuentas bancarias, todo ello número utilidad específica API estáticas iría a org.mycompany.util.Numbers

API Todos "cuenta" de reglas de negocio específica ayudando iría a

org.mycompany.account.AccountHelper 

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

+4

Parece razonable, que Helper sería más específico que Utils. – KajMagnus

+0

Sí, me gusta este enfoque, es más lógico. – Conan

+0

El enlace está roto. Encontré [otro] (http://www.cs.bc.edu/~muller/teaching/cs102/s06/lib/pdf/api-design). – Chavjoh

Cuestiones relacionadas