Méritos de los nombres / paquetes

Algunos lenguajes de programación (por ejemplo, Java y C ++) tienen características de lenguaje llamadas "paquetes" o "espacios de nombres". ¿Qué tan útil es realmente tener espacios de nombres? Es posible marcar funciones y clases como pertenecientes a alguna biblioteca en particular sin usar una función de lenguaje como la SDL (p SDL_BlitSurface(). Ej .). ¿Los espacios de nombres no son lo suficientemente útiles como para valer la pena? ¿Son útiles en bibliotecas pero no en aplicaciones? ¿Son útiles en todas partes, excepto en pequeños proyectos? Pensamientos?

¿No son los prefijos de nombre lo mismo que el espacio de nombres , excepto que se hace de una manera que es menos útil y más difícil de leer / analizar? ¿La pregunta no se responde sola?

La mayoría de los idiomas (¿todos?) Con espacios de nombres tienden a estar orientados a objetos. Muchas veces es apropiado un nombre legible para un tipo, aunque existen múltiples implementaciones incompatibles. (Esto plantea otros problemas sobre la reutilización orientada a objetos, pero de eso no se trata esta pregunta). Por ejemplo, en Java tiene un temporizador que se utiliza para tareas de IU en segundo plano y un temporizador que se utiliza para tareas de aplicación en segundo plano (no vinculadas a AWT / Swing). El espacio de nombres le permite tener estos objetos con el mismo nombre viviendo en diferentes sub-API.

La razón por la que surgieron los espacios de nombres tuvo que ver con la irrazonable tarea de anticipar lo que otros desarrolladores nombrarán sus objetos. C ++ introdujo el concepto (o al menos fue el primer idioma al que estuve expuesto con el concepto), y fue útil a pesar de que no había pautas sobre las mejores prácticas de uso. Java adaptó el concepto y agregó algunas "mejores prácticas" que incluyeron el nombre de su empresa en el espacio de nombres. De esa manera, solo tenía que preocuparse por su propia empresa.

Los prefijos pueden volverse bastante desordenados. ¿Cuándo lo aplicas? ¿Cuándo no lo aplica? ¿Las estructuras / clases / métodos globales obtienen el prefijo? ¿Qué hay de los métodos? ¿Qué pasa con las propiedades en la estructura? He visto todas estas cosas en código, aunque afortunadamente no todas a la vez. Los espacios de nombres proporcionan cierta previsibilidad a todas estas preguntas y lo convierten en una característica del lenguaje en lugar de una "mejor práctica" personal.

Creo que los espacios de nombres son una gran idea. Ayudan a evitar conflictos de nombres al limitar el alcance de un nombre. En los paquetes Java, la convención de nomenclatura de paquetes sugerida se basa en nombres de dominio, que deberían ser únicos, que ayudan a evitar conflictos de nomenclatura sobre bibliotecas personalizadas. En general, hacen que nombrar sea un poco más único en el sentido amplio, al tiempo que le permiten al programador un poco más de libertad para nombrar sus piezas sin tener que seguir alguna convención de nomenclatura oscura.

Los espacios de nombres / módulos / paquetes son útiles para evitar conflictos de nombres. También lo es el prefijo de nombres, pero los espacios de nombres tienen la conveniencia adicional de poder importar símbolos en el espacio de nombres actual para que no tenga que preocuparse por todo el Espacio de nombres :: *.

Algunos lenguajes (como Python) amplían esta capacidad al permitirle importar solo símbolos específicos en su módulo actual o importar símbolos con un nombre diferente. Esto es útil si solo está interesado en algunas clases / funciones / constantes o si algunos de los símbolos entran en conflicto con los símbolos en su espacio de nombres pero otros no.

Algunos idiomas (como Ruby) le permiten incluir los métodos de un módulo en su clase. Esto es útil para el polimorfismo y los genéricos. Por ejemplo, si tiene varias clases que tienen iteradores que actúan de la misma manera, puede mezclar métodos en todas estas clases desde un módulo separado que proporciona métodos para ordenar y filtrar los datos en el objeto. Esto permite has arelaciones así como is a(herencia) relaciones.