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?
We're all familiar with the Java package name convention of turning the domain name around.- um..no no estamos ... :)com.java.etc.etc. Apache (en el sitio Apache.org) nombra sus paquetesorg.apache.etc.etc. Ves el patrón.Respuestas:
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.
Si incluso el nombre de su empresa es inestable, es posible que desee comenzar con el nombre del producto.
fuente
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
La convención no tiene fallas. La gente tiene defectos, como bien te has ilustrado.
Puedo pensar en 2 beneficios:
fuente
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:
o
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
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.
fuente