Cómo lidiar con las clases que tienen el mismo nombre (paquetes diferentes)

Mi equipo de I + D y yo mantenemos una gran base de código. Hemos dividido nuestra lógica de negocios en múltiples paquetes. algunos de los cuales tienen clases con nombres idénticos .

Como puede adivinar, los nombres entran en conflicto cuando se hace referencia a ambas clases en el mismo archivo Java.

Por ejemplo:

com.myapp.model (package)
 - Device (class)
 - ...

com.myapp.data (package)
 - Device (class)
 - ...

Tuvimos un debate sobre cuál es la mejor práctica para tratar estos casos y surgieron las siguientes opciones:

Primera opción

• Cambiar el nombre de la clase, agregar un prefijo

  ModelDevice
  DataDevice

2da opción

• Usar el paquete completo + nombre de clase cuando se hace referencia a ambos

  com.myapp.model.Device
  com.myapp.data.Device

¿Qué es más correcto en términos de gestión de código y escalabilidad?

Actualmente estamos mezclando ambos enfoques y comenzamos a tener inconsistencias

Usa el nombre del paquete. Este tipo de problema es precisamente por qué Java usa la convención de nomenclatura de paquetes que hace. Previene este tipo de problemas, ya sean dos equipos en la misma compañía o dos equipos en lados opuestos de la tierra.

A partir de ahora tiene una clase ModelDevice (Dispositivo en el paquete del modelo). ¿Qué sucede si tiene otro ModelDevice para una clasificación diferente? El problema aún puede persistir y los gastos generales también continuarán aumentando.

Aunque por el momento puede encontrar que cambiar el nombre de las clases puede ser de buena ayuda, a largo plazo, la alternativa sugerida es ir prefijando los nombres de los paquetes, que es lo que establece el Estándar de la Industria.

Solo para agregar un aspecto que aún no se ha mencionado:

Eche un vistazo a los patrones de uso, es decir, las fuentes de Java que hacen referencia a una o ambas clases.

En mi humilde opinión, en la mayoría de los casos, los archivos fuente deben hacer referencia solo a una de las clases en conflicto, y desde el contexto debe quedar claro si tratan con el modelo o el mundo de los datos. Si eso es difícil por alguna razón, cambiaría el nombre de las clases, ya que generalmente no me gustan los nombres de clase con prefijo de paquete en el código fuente (degrada la legibilidad).

Si tiene archivos de origen que tratan con ambos mundos, podrían estar uniendo clases con la responsabilidad de traducir entre dos vistas diferentes del mundo, y aquí preferiría encontrar nombres de clase con prefijo de paquete.

Pero ver ambas clases de dispositivos en una sola fuente podría ser una pista de que la fuente viola el principio de responsabilidad única al mezclar tareas del modelo y el mundo de los datos.