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

9

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

— Jossef Harush
fuente

Si es ocasional, probablemente no importe; si es un patrón recurrente, probablemente nombraría las clases con mayor precisión para evitar que se convierta en un desastre.

— Assylias

No tienes idea de cuánto odio java.util.Datey java.sql.Date, especialmente porque java.sql.Datees una subclase de java.util.Datey se desliza muy bien fuera de las capas de datos (y no serializa muy bien a JSON).

Opción 2.1 Utilice siempre el nombre completo, incluso si el otro no está referenciado

— Caleth

18

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.

— Bryan Oakley
fuente

1

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.

— itsraghz
fuente

0

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.

— Ralf Kleberhoff
fuente