¿Cómo evitas las similitudes de nombres entre tus clases y las nativas? [cerrado]

9

Me encontré con un "problema interesante", sobre el cual me gustaría su opinión:

Estoy desarrollando un sistema y por muchas razones (es decir, abstracción, independencia tecnológica, etc.) creamos nuestros propios tipos para intercambiar información.

Por ejemplo: si hay un método que se llama SendEmail y es invocado por la lógica de negocios, tiene un parámetro de tipo OurCompany.EMailMessage, que es un objeto que es completamente independiente de la tecnología y contiene solo "datos relevantes para el negocio" (para instancia, no hay información sobre la codificación de la cabeza).

Dentro de la función SendEmail, obtenemos esta información de nuestro objeto EMailMEssage y creamos un objeto MailMessage (este es específico de la tecnología) para que pueda enviarse a través de la red.

Como ya puede notar, nuestra clase tiene un nombre muy similar a la clase de idioma "nativo". El problema es: esto es exactamente lo que son, mensajes de correo electrónico, por lo que es difícil encontrar otro nombre significativo para ellos.

¿Tienes este problema a menudo? ¿Cómo lo manejas?

Editar: @mgkrebbs acaba de comentar sobre el uso de nombres completos. Este es nuestro enfoque actual, pero un poco demasiado detallado, en mi humilde opinión. Me gustaría algo más limpio, si es posible.

naming coding-standards variables

— JSBach
fuente

2

Siempre usar la calificación parece una solución viable, aunque un poco detallada. Use OurCompany.EMailMessage para un tipo y SendEmailClass.EMailMessage (o lo que sea) para el otro. ¿Hay algún problema con este enfoque?

— mgkrebbs

Sí, lo pensé, pero se vuelve detallado. Me gustaría algo "más limpio", pero la solución que propuso es la actual. Agregaré esto a la explicación

— JSBach

3

Los nombres vienen en un contexto. Por lo general, un espacio de nombres o algo así. Entonces no debería ser un problema.

— deadalnix

+1, me gusta esta pregunta. Una vez pregunté a esta pregunta a un instructor hace alrededor de 7 años, y él pensaba que yo soy un completo "...." :)

— NoChance

Qué idioma estás usando? La respuesta es específica del idioma. En general, la respuesta es 'usar un espacio de nombres'. En una sola aplicación Java, es bastante común tener el mismo nombre de clase utilizado por media docena de bibliotecas.

— Kevin Cline

3

Este es un problema sobre el espacio de nombres que va a utilizar para su proyecto.

Básicamente, un espacio de nombres es la colección de palabras clave proporcionadas por todas sus clases y / o todas las clases que desea usar en su proyecto (incluidas las clases estándar que generalmente se proporcionan con el idioma / compilador / IDE).

Dado que un espacio de nombres es una colección, básicamente se aplican algunas reglas para evitar la creación de un desorden de términos sin ningún comportamiento relacionado, y algunos lenguajes como C # también le permiten definir su propio espacio de nombres como de costumbre y también usarlo en otras clases.

No confunda el espacio de nombres con la palabra clave básica del idioma, ambos son una colección de palabras clave pero con una gran diferencia entre los dos: puede modificar un espacio de nombres pero generalmente no puede modificar las palabras clave básicas de un idioma. La suma entre el espacio de nombres que ha utilizado en su proyecto y las palabras clave básicas del idioma que utiliza le proporciona la cantidad total de palabras clave.

El tema es muy discutido en la red, puedo sugerir una búsqueda básica con los términos "espacio de nombres [su idioma]" o algo así. No estoy respondiendo directamente a su pregunta simplemente porque puede tener un enfoque diferente para diferentes idiomas.

— Micro
fuente

3

Bueno, mi antiguo equipo de desarrollo solía agregar el acrónimo de la aplicación en cada clase personalizada. Tuvimos, por ejemplo, la clase ABCEmail .

Creo que es más sencillo que confiar en el espacio de nombres, pero también puede ser una solución complementaria al uso del espacio de nombres.

Por último, pero no menos importante, ya que está creando un nuevo objeto, significa que el objeto nativo no responde a sus necesidades, por lo que su nombre de su archivo de correo electrónico podría ser CustomizedEmail , AdvancedEmail ... etc.

— Amina
fuente

1

De acuerdo con su punto final, pero ¿por qué sería OAEmailmejor que OurApplication.Email? OAEMailtiene un impacto en cada parte del software, mientras que la notación del espacio de nombres solo tiene un impacto allí donde ocurre la conversión y ambas clases se usan en el mismo archivo fuente.

— Steven Jeuris

1

Creo que el prefijo es una buena idea cuando su idioma no admite espacios de nombres. Pero si el lenguaje es compatible con algún tipo de namespacing luego usarlo (esto es los espacios de nombres de problemas fueron diseñados para resolver!) `.

— Martin York

@ Steven Jeuris: El nombre de la clase debe seleccionarse una vez que se crea. Después, me parece una mala práctica cambiarlo ... debido a todos los impactos innecesarios.

— Amine

@Loki Astari: no sé qué IDE está utilizando, pero creo que un nombre de clase diferente es más fácil de manejar al buscar o abrir una clase determinada. Vi proyectos que tenían una versión personalizada de "correo electrónico" y cada vez que quería abrir el archivo tenía que examinar varios espacios de nombres. Su punto sigue siendo válido. Supongo que es subjetivo para la organización del paquete cuántas clases personalizadas se crearán.

— Amine

1

@Amine: No me di cuenta de que en realidad estás discutiendo en contra de los espacios de nombres. Le sugiero que lea sobre los espacios de nombres un poco más para ver todas las ventajas de usarlos: encapsulación, eliminación de la ambigüedad, menos redundancia, ... Ps: La mayoría de los IDE modernos tienen características de búsqueda que le permiten encontrar rápidamente un archivo fuente sin tener que navegar a través de ellos. La jerarquía. En cuanto a su comentario para mí: la refactorización constante es parte del desarrollo de software. Cuando pueda encontrar un nombre más adecuado, de gran impacto o no, debería considerar cambiarle el nombre. Sin embargo, es mejor discutir esto con sus colegas primero.

— Steven Jeuris el

3

Qué idioma estás usando? La respuesta es específica del idioma. En general, la respuesta es 'usar espacios de nombres'. Casi nunca destrozaría el nombre del tipo para evitar un conflicto con algún espacio de nombres externo.

En una sola aplicación Java, es bastante común tener el mismo nombre de clase (por ejemplo, "Fecha") definido en media docena de espacios de nombres. Si una clase necesita usar dos clases de Fecha separadas, entonces una de las clases de Fecha debe estar completamente calificada en todas partes, ya que Java no admite alias de tipo. En C ++ la vida es más fácil; puedes cambiar el nombre de uno de ellos con typedef.

— Kevin Cline
fuente

Estaba a punto de publicar una respuesta similar, pero en lugar del ejemplo de alias de C ++ quería mencionar a C # usando la directiva de alias .

— Steven Jeuris

@ Steven: iba a mencionar C # en lugar de C ++, pero han pasado algunos años desde que programé en C #, y no estaba seguro.

— Kevin Cline

2

¿Tienes este problema a menudo? ¿Cómo lo manejas?

Realmente depende del idioma que uses. En c ++ y java, este problema se resuelve utilizando espacios de nombres. Estoy usando c ++, y sucede que obtuve diferentes clases con el mismo nombre. No es un problema, ya que están en diferentes espacios de nombres.

En otros idiomas, no hay formas de evitarlo, sino proporcionar nombres diferentes.

— BЈовић
fuente

Para la computadora no es un problema, pero para el desarrollador podría serlo, ya que tiene EmailMessage y MailMessage, por ejemplo.

— JSBach

@Oscar Obviamente. Para la computadora puede ser xyz123y aún funciona igual. No veo otra forma de decir en detalle (usted dijo en los comentarios que está tratando de evitarlo).

— B 24овић

2

Tu pregunta es muy buena. ¿Qué tal si prefijas tu método con un prefijo como U (uu) o cls (abreviatura de clase)? Por ejemplo:

clsEMailMEssage o uEMailMEssage

Esto no requiere mucho tipeo e inmediatamente se nota que el tipo es 'suyo'.

Editar - En respuesta a los primeros 2 comentarios:

Me gustaría señalar la atención del lector al hecho de que: No todas las anotaciones húngaras se crean de la misma manera. Deberíamos distinguir entre Sistema húngaro y Aplicaciones húngaras , supongo que la sugerencia anterior sigue el tipo de Aplicaciones húngaras, que no es dañino.

El daño asociado con la notación húngara del sistema, como nombrar una ID como intID, no está presente en la sugerencia anterior.

Para obtener más información sobre esto, eche un vistazo a: Hacer que el código incorrecto parezca incorrecto - Joel On Software

— Ninguna posibilidad
fuente

3

Cada vez que alguien recomienda la notación húngara, Dios mata a un gatito.

— Konamiman

2

BIgHUmpCAmelCAsing tampoco ayuda.

— Steven Jeuris

Los comentarios anteriores son apreciados. Por favor, vean mis ediciones, aunque sé que algunos de nosotros no cambiaremos de opinión, después de todo, ¿quién quiere matar a un gatito? :)

— NoChance

Eliminé el voto negativo ahora que agregaste un razonamiento válido. Sin embargo, no estoy de acuerdo con que Apps Hungarian sea más apropiado que los espacios de nombres en este escenario. Cuando el lenguaje admite alias, esa es una solución mucho más adecuada. Ver la respuesta de Kevin Cline .

— Steven Jeuris el

@ Steven Jeuris, gracias por tu comentario. Los espacios de nombres son perfectos, excepto que son un poco largos para seguir escribiendo, comprobaré el enlace que ha proporcionado.

— NoPuerto