¿La convención de nombre de paquete Java tiene fallas? [cerrado]

28

Todos estamos familiarizados con la convención de nombres de paquetes Java de cambiar el nombre de dominio. Es decir www.evilcorp.com, por convención, elegiría tener sus paquetes java com.evilcorp.stuff.

Cada vez más me estoy hartando de esto. Como programador comercial, encuentro una y otra vez que el nombre del paquete de software es completamente irrelevante debido a algún cambio de marca, adquisición o similar.

En el mundo de código abierto hay menos cambios de nombre, por lo que tiene sentido. Sin embargo, me parece que la vida útil de muchas piezas de software (comercial / interno) es mucho más larga que la de la organización que las fabrica.

El problema a menudo se agrava por los proyectos de software que toman el liderazgo del departamento de marketing para usar el nombre del día que usan para referirse a un determinado proyecto. Un nombre que, sin falta, cambiará 3 meses más adelante para que la ropa nueva del emperador se sienta fresca y nueva.

Debido a esto, he dejado de usar el dominio inverso como nombre del paquete. De acuerdo, si esto se hace a gran escala, existe el riesgo de colisiones de nombres, pero seguramente esto se mitiga mediante el uso de nombres de software "únicos", evitando palabras genéricas, o usando el dominio inverso para proyectos destinados a ser vendidos / liberados como bibliotecas .

¿Otros pensamientos?

java naming Martin Algesten
fuente
2
We're all familiar with the Java package name convention of turning the domain name around.- um..no no estamos ... :)
Dr. Hannibal Lecter
8
@dr Hannibal Lecter: Bastante simple. Java (en el sitio Java.com) nombra sus paquetes com.java.etc.etc. Apache (en el sitio Apache.org) nombra sus paquetes org.apache.etc.etc. Ves el patrón.
doppelgreener el
3
@dr Hannibal Lecter: cf. docs.oracle.com/javase/tutorial/java/package/namingpkgs.html
user359996
1
"En el mundo de código abierto hay menos cambios de nombre", incluso allí es un problema, a menudo veo proyectos que ahora están en say github pero los nombres de sus paquetes revelan que solían estar en el reverso de net.sourceforge.xxx o com. googlecode.xxx
nafg
@nafg: correcto. Es por eso que tiendo a registrar mi propio nombre de dominio para cualquier proyecto de código abierto en el que empiezo a trabajar en estos días, porque no necesariamente quiero vincular su identidad a alguna corporación específica (ya sea como sourceforge o github que le proporciona un servicio, o uno como mi propia compañía que proporcionó la motivación original para desarrollarlo). Necesita ser libre para ser lo suyo.
Jules

Respuestas:

23

Voy a citar los consejos que Microsoft da para los espacios de nombres (paquetes de .NET), que no tienen la convención de nombres de dominio. Creo que también es un buen consejo para los paquetes Java, ya que no creo que un nombre de dominio represente una identidad sólida y estable.

El formato general para un nombre de espacio de nombres es el siguiente:

<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]

Por ejemplo, Microsoft.WindowsMobile.DirectX.

Haga prefijos de nombres de espacios de nombres con el nombre de una compañía para evitar que los espacios de nombres de diferentes compañías tengan el mismo nombre y prefijo.

Utilice un nombre de producto estable e independiente de la versión en el segundo nivel de un nombre de espacio de nombres.

No utilice las jerarquías organizacionales como base para los nombres en las jerarquías de espacios de nombres, porque los nombres de grupos dentro de las corporaciones tienden a ser de corta duración.

El nombre del espacio de nombres es un identificador de larga duración e inmutable. A medida que las organizaciones evolucionan, los cambios no deberían hacer que el nombre del espacio de nombres quede obsoleto.

Si incluso el nombre de su empresa es inestable, es posible que desee comenzar con el nombre del producto.

Allon Guralnek
fuente
3
¿Qué recomienda Microsoft que haga si otra compañía tiene el mismo nombre que el suyo?
25
@ Thorbjørn - litigio
RevBingo
99
@ Thorbjørn: un espacio de nombres, a diferencia de un dominio, no es ni puede ser propiedad de nadie. Es solo una división lógica o categorización de código. Las posibilidades de colisión entre usted y esa otra compañía se acercan a cero, a menos que esa otra compañía también desarrolle software, en la misma tecnología, y tenga una oferta similar (en resumen, un competidor suyo). En ese caso, tomaría la sugerencia de RebBingo, a menos que esté de acuerdo con tener una compañía competidora que tenga el mismo nombre que su compañía.
Allon Guralnek
44
Como se señaló en la respuesta de @ Thorbjørn, el problema que resuelve la convención de nomenclatura de Java no es garantizar la constancia sino garantizar la unicidad . Tenga en cuenta que la convención de Microsoft no garantiza ninguno .
user359996
44
@ user359996: Como dije, no veo por qué la unicidad universal es un problema que necesita solución. ¿Por qué necesitaría nombres para ser únicos en bases de código mutuamente excluyentes? Y el estilo de Java no lo garantiza , ya que la propiedad de los nombres de dominio puede cambiar de manos. Un desarrollador que posee jUtils.com puede desarrollar una biblioteca com.jutils. * Que muchos usan, y luego vender su dominio a un desarrollador completamente diferente que desarrolle una biblioteca com.jutils. * Diferente que también es popular, pero tiene colisiones con el biblioteca existente
Allon Guralnek
15

Está buscando la solución a un problema diferente, a saber, ¿cómo evitamos que el programador X y el programador Y pisen los dedos de los demás colocando los archivos en el mismo paquete?

El "simplemente invierta su nombre de dominio" resuelve esto de una manera elegante, ya que entonces está bastante seguro de que si X e Y no están relacionados, no elegirán el mismo espacio de nombre de paquete.


fuente
+1 "Estás buscando la solución a un problema diferente".
user359996
10

La convención no tiene fallas. La gente tiene defectos, como bien te has ilustrado.

Puedo pensar en 2 beneficios:

  1. Evita la colisión entre desarrolladores independientes. Un dominio es único. Dos personas pueden nombrar dos proyectos diferentes de la misma manera, pero un dominio tiene exactamente un propietario.
  2. Hace que sea más fácil encontrar al mantenedor. Si hereda una base de código, que usa alguna biblioteca de código abierto, es mejor que esté en un paquete que lo ayude a encontrarla. Por ahora no importa, porque seguramente podrás googlearlo. Pero hace 10 años, esto no era tan evidente.
back2dos
fuente
7

El nombre de dominio inverso se usó para evitar colisiones de nombres en caso de que diferentes organizaciones usen los mismos nombres de clase en sus bibliotecas. Es una solución simple y fuera de la fuente tiene algunos inconvenientes (por ejemplo, ¿qué pasa con las colisiones de nombres para las clases en la misma organización?).

No está obligado a usarlo, es una convención, no una regla de hacer o morir. Por ejemplo, algunos programadores de Java no respetan las convenciones de código de Java .

Pero considere las alternativas. ¿Cómo le gustaría, por ejemplo, dos nombres de clase completamente calificados para un LogFactory:

a50e8400_e29b_41d4_a716_446655440000.LogFactory
f47ac10b_58cc_4372_a567_0e02b2c3d479.Logfactory

o

org.apache.commons.logging.LogFactory
com.evilcorp.logging.LogFactory

Entonces, en mi opinión, usa lo que quieras siempre que incluya sentido común y consideración para los usuarios de tu biblioteca.


fuente
4

Cuando comienzo un nuevo proyecto, siempre insisto en un nombre interno e inmutable que las personas de marketing puedan conocer o no, ya que solo se mencionará en el código fuente. De esa manera, no tengo que preocuparme por los cambios de nombre del proyecto y la contaminación del espacio de nombres.

Este escenario me queda bien, porque el código fuente no suele ser una parte importante del producto, es decir, los proyectos suelen ser sistemas de código cerrado y propietarios. Sin embargo, en proyectos de código abierto donde el código fuente es el producto, esto podría no ser factible.

SWeko
fuente