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

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?

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.

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.

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.

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.

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.