¿Nombre de paquete semánticamente más apropiado que 'util' para las siguientes cosas?

Como un hombre de paja, considere el paquete java.util, es un vertedero para varias clases que, en la mayoría de los casos, no comparten nada en común, aparte de la persona que los puso allí, fue flojo o sin inspiración para encontrar un nombre de paquete más semánticamente correcto para su clase.

Como un ejemplo, tomemos la clase UUID¿cuál habría sido un nombre de paquete semánticamente correcto para esa clase?

Estoy trabajando en implementar mi propia UUIDclase para ser más liviano. No quiero usar me.myproject.util.UUIDpara el nombre de mi paquete.

Lo consideré me.myproject.rfc4122.UUIDpero eso no implica la semántica del uso de UUID.

También consideré, me.myproject.uuid.UUIDpero no me gusta la tautología en eso, a pesar de que es un enfoque popular en Python poner una clase en un módulo con el mismo nombre, y packagesen Java no son semánticamente equivalentes a modulesPython.

También lo consideré, me.myproject.UUIDpero lo rechacé porque no quiero contaminar esa parte del espacio de nombres con cosas que no están relacionadas. Esto solo mueve el problema a un nivel superior.

También lo consideré, me.myproject.lib.UUIDpero esto no tiene más significado semántico que .utily solo cambia el nombre del problema.

semantics: la rama de la lingüística y la lógica relacionada con el significado .

El problema al tratar de poner cada clase en un paquete que tiene un nombre semánticamente correcto para esa clase es que tiende a conducir a paquetes que contienen muy pocas clases o, a veces, solo una clase. Esto a su vez conduce a una multitud de paquetes.

Un enfoque más pragmático para nombrar paquetes es simplemente ayudarlo a encontrar cosas. Mantener las cosas de uso frecuente que siempre sabes dónde encontrarlas agrupadas en un solo lugar las mantiene alejadas y, por lo tanto, hace que sea más fácil encontrar las cosas que se usan con menos frecuencia. Por lo tanto, realmente no necesita nombres de paquetes que sean semánticamente correctos para cada una de las clases que contienen, solo necesita nombres de paquetes que no sean semánticamente incorrectos. Obviamente, el nombre del paquete 'util' se eligió de acuerdo con esta línea de pensamiento: no es el nombre semánticamente correcto para las clases que contiene, pero tampoco es semánticamente incorrecto, y eso es lo suficientemente bueno.

Por lo tanto, si este tipo de UUID suyo está destinado a ser utilizado solo por esta aplicación específica (como lo demuestra el hecho de que planea ponerlo en 'mi proyecto'), entonces probablemente sea parte del 'modelo' de su proyecto. Ya debe tener un paquete 'modelo', que contenga el conjunto de todas las clases que corresponden a sus entidades persistentes, muchas de las cuales probablemente tengan relaciones entre ellas, y los UUID probablemente sean los medios para implementar estas relaciones. Además, sus UUID probablemente saben cómo persistir, ¿verdad? Y también, sus UUID probablemente solo se puedan encontrar como miembros de sus entidades modelo, ¿verdad? Por lo tanto, su paquete modelo es probablemente el mejor lugar para ello.

De lo contrario, si este tipo de UUID suyo también se puede usar en otros proyectos, entonces debe verse como parte de algún marco. Por lo tanto, puede vivir en la carpeta fuente raíz de ese marco, o en algunos subpaquetes de 'tipos' como sugirió MainMa, o incluso en algún subpaquete de ese marco llamado 'util' o 'misc'. Nada de malo con eso.

El propósito de los paquetes es agrupar las clases de acuerdo con algunos criterios (paquete por tipo / capa vs. paquete por característica, etc.). Realmente no veo un punto para crear un paquete para una sola clase, especialmente si no esperas que haya otras clases en este paquete en el futuro.

También creo que el nombre del paquete "util" no tiene ningún significado, solo agrupa las clases según un criterio específico, para mí la clase "util" significa que no es parte del dominio de la aplicación, pero tampoco es parte del framework (no influye en la estructura de la aplicación). Básicamente es solo una extensión de la biblioteca (no) estándar.

En este caso, no tendría problemas para poner esta clase UUID en el paquete "util". Si habrá otras clases de utilidad relacionadas con UUID (como una clase separada para generar UUID), es fácil refactorizar y crear el paquete "util.uuid" para ellos (a menos que esté creando una biblioteca y UUID será parte de la interfaz expuesta) , entonces debes ser un poco "progresista").

El tío Bob tiene algunas pautas sobre la separación de paquetes.

Los primeros tres principios del paquete son sobre la cohesión del paquete, nos dicen qué poner dentro de los paquetes:

1. El gránulo de reutilización es el gránulo de liberación
2. Las clases que cambian juntas se empaquetan juntas
3. Las clases que se usan juntas se empaquetan juntas

Entonces, respondiendo a su pregunta, ¿quién / qué va a usar la clase UUID, la tiene como atributo o invoca operaciones en ella? ¿Cómo es tu gráfico de dependencia ? ¿UUID se usará junto con qué otras clases ?

Dependiendo de su respuesta, tal vez debería llamarlo el me.myproject.identity paquete, el me.myproject.serialization paquete, me.myproject. DTO o incluso algo completamente diferente. Tal vez, la clase UUID debe mantenerse junto con sus modelos y la colocará en un paquete que ya tiene, como yo.myproject.models .

En primer lugar, UUID (con mayúsculas) me parece una muy mala idea para el nombre del paquete o el nombre de la clase, de todos los estilos aplicados de una forma u otra, todos los nombres en mayúscula están asociados con las "constantes". Los paquetes están destinados a organizar cosas, la forma más fácil de nombrar un paquete es por el valor de las clases que contiene:

• puede elegir separar las clases por su valor comercial, por ejemplo com.example.identifier;
• o por su valor técnico, por ejemplo com.example.uuid.

Mantenga la TI simple