¿Mala práctica tener dos clases del mismo nombre en diferentes paquetes?

Hemos dividido nuestra aplicación para que el paquete A maneje los datos de una fuente externa y el paquete B de otra. En ambos casos, necesitamos crear un objeto de dominio y tener un "Transformer" para hacer esto.¿Mala práctica tener dos clases del mismo nombre en diferentes paquetes?

Así que tienen com.foo.bar.a.ThingTransformer y com.foo.bar.b.ThingTransformer

Sospecho que esta es una mala práctica, pero quieren ver lo que la buena gente de pensar que sí.

Fuente

2011-07-11 Paul McKenzie

No llegaría tan lejos como para decir que siempre es una mala práctica, pero es algo así como code smell.

Si ambas clases no cosas diferentes, entonces ¿por qué no tienen nombres diferentes?

si ambas clases do lo mismo, entonces ¿por qué hay dos clases?

Desde un punto de vista práctico puede llegar a ser muy molesto si alguna vez necesita esas dos clases que se hace referencia en la misma clase: usted tendrá que usar el FQN para uno de ellos (probablemente sería mejor para usarlo para ambos en este caso, para mayor claridad). Si esas dos clases se encuentran en partes del código suficientemente distintas que no serán referenciadas desde el mismo código, entonces el problema práctico no es tan malo.

Fuente

2011-07-11 08:24:59

estoy manteniendo un proyecto en el que el patrón está por todas partes. Varias clases con los mismos nombres, en diferentes carpetas. A veces tengo ganas de perseguir a quien es responsable de eso y darles una paliza. – Mirko

No hay nada de malo en eso, ya que es muy poco probable que use ambas clases juntas en el mismo código. Duplicar la distinción a/b del paquete en todos los nombres de clases sería peor.

Fuente

2011-07-11 08:25:11

+1 por no duplicar información de espaciado entre nombres en el nombre simple! –

No es realmente una mala práctica, ya que en muchos dominios tiene una terminología similar, por lo que terminará teniendo los mismos nombres. Por otro lado, si ambos están en el mismo dominio, pero simplemente implementaciones diferentes, puede (de alguna manera) indicar los detalles de la implementación en el nombre.
Lo más feo sería si tiene que usar ambos en el mismo archivo de origen, en este caso debe usar un nombre completamente calificado para al menos uno.

Ejemplos:

java.util.List java.awt.List

indican aplicación en el nombre:
java.util.ArrayList
java.util.LinkedList

Fuente

2011-07-11 08:25:56

+1 para mencionar el hecho de que los diferentes dominios tienen una terminología similar. Por ej. Lucene tiene una clase de documento que estoy seguro es un nombre que podría aparecer fácilmente en otra API. – lightalchemist

Está bien. Esta es precisamente la razón por la cual, por diseño, diferentes paquetes tienen diferentes espacios de nombres.

Fuente

2011-07-11 08:27:08

Tiene que decidir si esto es más útil o más confuso. Puede obtener el mismo problema al usar nombres similares en el mismo paquete donde la diferencia no es clara.

Un ejemplo del más confuso de lo útil es algo así como

com.sun.corba.se.internal.Interceptors.PIORB extends 
com.sun.corba.se.internal.POA.POAORB which extends 
com.sun.corba.se.internal.iiop.ORB which extends  
com.sun.corba.se.impl.orb.ORBImpl which extends 
com.sun.corba.se.spi.orb.ORB which extends  
com.sun.corba.se.org.omg.CORBA.ORB which extends 
org.omg.CORBA_2_3.ORB which extends 
org.omg.CORBA.ORB

Fuente

2011-07-11 08:38:55

¿Mala práctica tener dos clases del mismo nombre en diferentes paquetes?

Respuesta

Cuestiones relacionadas