¿Por qué tantos espacios de nombres comienzan con com


45

Me he dado cuenta de que muchas empresas usan espacios de nombres de "nombre de dominio inverso" y tengo curiosidad por saber dónde se originó esa práctica y por qué continúa. ¿Continúa simplemente debido a la práctica rutinaria, o hay un concepto de arquitectura sobresaliente que podría estar perdiendo aquí?

También tenga en cuenta preguntas como: https://stackoverflow.com/questions/189209/do-you-really-use-your-reverse-domain-for-package-naming-in-java que responde mi pregunta pero no 100 %

(Si te hace sentir mejor, tengo mucha curiosidad si debería usarlo para mis esfuerzos de espacio de nombres de JavaScript, pero tengo más curiosidad sobre cuándo y por qué, y eso debería ayudarme a guiarme en la respuesta de JavaScript, nota bene: "ventana")

Ejemplo de esta práctica que se extiende a carpetas y archivos: http://imgur.com/jtdXo


1
Esto es extraño, nunca había visto esto antes ... ahora tengo curiosidad.
Jimmy Hoffa

Respuestas:


54

La notación de dominio inverso tiene su origen en Java, pero se usa ampliamente en muchas plataformas, como paquetes de Android, paquetes de Mac OS X, JavaScript, ActionScript y más.

La práctica es extremadamente útil porque proporciona un sistema descentralizado para el software de espacio de nombres. No hay necesidad de solicitar una agencia centralizada para un espacio de nombres; simplemente use el nombre de dominio que posee (al revés) y adminístrelo dentro de su propia organización. Al nombrar paquetes como este, uno puede estar casi seguro de que el código no entrará en conflicto con otros paquetes.

De los Tutoriales Java de Oracle :

Las empresas usan su nombre de dominio de Internet invertido para comenzar sus nombres de paquete, por ejemplo, com.example.mypackage para un paquete llamado mypackage creado por un programador en example.com.

Las colisiones de nombres que ocurren dentro de una sola compañía deben manejarse por convención dentro de esa compañía, quizás incluyendo la región o el nombre del proyecto después del nombre de la compañía (por ejemplo, com.example.region.mypackage).

Es más que una práctica rutinaria, es una buena práctica porque es un espacio de nombres completo y completamente específico . Si hubiera dos compañías llamadas Acme y ambas eligieran el espacio de nombres acme., su código entraría en conflicto. Pero solo una de esas compañías puede ser propietaria del dominio acme.com , por lo que pueden usar el com.acme.espacio de nombres.

Invertir el nombre de dominio permite una arquitectura de arriba hacia abajo. comcontendría código para compañías (o cualquier persona que posea un nombre de dominio .com), y debajo de eso habría nombres de compañía (dominio). Entonces, más profundo dentro de eso sería la estructura de la organización y / o el espacio de nombres real. (Por ejemplo, si se trata de un código de una red llamada internal.acme.com , eso le da a este departamento su propio sub-espacio de nombres com.acme). Esta estructura de arriba hacia abajo se usa en varias aplicaciones, incluida la administración de sistemas. (Es similar a la búsqueda inversa de direcciones IP).

Personalmente, lo uso para todos los nuevos códigos JavaScript que escribo para mi empresa. Asegura que el código nunca entrará en conflicto con ningún otro código, incluso si luego escribo el mismo código para otra compañía. Puede hacer que el acceso al código sea engorroso (escribir com.digitalfruition.puede ser un poco demasiado), pero eso se puede solucionar fácilmente con un cierre y una variable local ( var DF = com.digitalfruition).


Debería pensar en cambiar el nombre de paquete aleatorio de mi aplicación de Android ... o comprar ese dominio. :(
jadkik94

Me pregunto si alguien encontró una manera de resolver el problema de tener un nombre de empresa que comience con un número como 123ABC.com, qué convención de nombres debería usar en este caso, donde Java no le permitiría tener ningún nombre de clase que comience con ¡¿un número?!
sorin

1
@sorin: prefija la parte relevante del nombre de su paquete con un guión bajo. Ej com._123ABC. Ejemplos en docs.oracle.com/javase/tutorial/java/package/namingpkgs.html .
cxw

13

Es porque usar espacios de nombres reduce enormemente las posibilidades de conflictos de nombres, y porque usar su nombre de dominio (que ya ha sido regulado) es una buena manera de crear un espacio de nombres global .

Al invertir la parte del dominio en el espacio de nombres, puede ordenarlo; Todos los nombres que pertenecen a su pequeño fragmento del universo del espacio de nombres se ordenan juntos.

Y por último, pero no menos importante, el TLD .comes el TLD más popular en Internet, por lo que es utilizado por más desarrolladores de software que cualquier otro TLD.

En cualquier caso, la práctica comenzó con Java, donde cada clase necesita tener su propio archivo, y para jugar en un ecosistema más grande, se introdujo el esquema de espacio de nombres global para ayudar a mantener las clases fáciles de calificar.


¿Se aplica estrictamente? Supongamos que intento crear el paquete com.xyz pero no soy dueño del dominio, ¿Android me impedirá hacerlo?
VarunAgw

@VarunAgw no, puedes jugar sucio y forzar conflictos.
Martijn Pieters

Además de los conflictos, tiene más sentido usar OrgName.ProjectName para proyectos pequeños entonces
VarunAgw

Estaría volando de cara a la convención, pero es su decisión.
Martijn Pieters

2

Endianness

No soy un experto en Java, pero en cuanto al patrón general, esta es solo otra permutación de big-endian vs little-endian, metafóricamente hablando.

"Endianness" a veces se usa para describir el orden de los componentes de un nombre de dominio, por ejemplo, 'en.wikipedia.org' (la forma moderna 'little-endian' habitual) versus el DNS inverso 'org.wikipedia.en' ( 'big-endian', utilizado para nombrar componentes, paquetes o tipos en sistemas informáticos, por ejemplo paquetes Java, archivos ".plist" de Macintosh, etc. Las URL pueden considerarse 'big-endian', aunque la parte del host podría ser un nombre DNS 'little-endian'.

En este caso, es presumiblemente para fines organizativos permitir la agrupación natural / ramificación de árboles. Mantiene las cosas ordenadas en un nivel superior, y usted busca más detalles específicos.

La alternativa sería muy plana, y la agrupación significativa / potencialmente útil debería interpretarse frente a ser intrínseca a la estructura.


77
Golly, nunca escuché endianness solía referirse al esquema de espacio de nombres de dominio inverso ..
Martijn Pieters

Yo tampoco, hasta que un colega lo lanzó en una conversación y generó una discusión tangencial. Refidió wikipedia (como vinculado a), por lo que aparentemente no es inaudito. Tuve que relajar un poco mi mente literal para acomodar este punto de vista, pero puedo vivir con ello.
Ed Hastings

3
Sí, esta discusión sobre la resistencia del DNS se produce periódicamente. La red "Janus", desaparecida hace mucho tiempo en el Reino Unido, tenía sus nombres al revés, y siempre decían que la multitud de ARPANet tenía las cosas al revés.
Ross Patterson

3
@RossPatterson: sistemas de archivos, sistemas operativos, sistemas de clasificación por facetas, sistemas de archivo de biblioteca, números de teléfono, la mayoría de ellos comienzan con la raíz a la izquierda y luego se vuelven más específicos. Diablos, incluso la mayoría de los archivos de configuración del servidor de nombres DNS lo hacen de esa manera. Entonces, estaría de acuerdo con la multitud de Janus.
Jörg W Mittag

1
@RossPatterson Dado su nombre, me sorprende que Janus tenga una opinión sobre lo que se considera "la forma correcta".
TRiG

0

Creo que no se mencionó un detalle menor en las otras respuestas: la razón por la que el TLD .com es el más popular, es que en los primeros días de la Web, los navegadores web como Netscape Navigator se "autoanexaron" .com si faltaba en la dirección (por ejemplo, si fallaba la búsqueda de nombre). Entonces, si escribió "shareware", se expandiría a " http://shareware.com " (o " http://www.shareware.com "; no recuerdo el detalle de www). Los dominios .com son probablemente los más populares.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.