oop - reglas - ¿En qué espacio de nombres debe colocar las interfaces en relación con sus implementadores?

reglas para el nombramiento de objetos variables constantes metodos y clases en java (9)

(.Net) Tiendo a mantener las interfaces en un ensamble "común" separado para poder usar esa interfaz en varias aplicaciones y, más a menudo, en los componentes del servidor de mis aplicaciones.

En cuanto a espacios de nombres, los mantengo en BusinessCommon.Interfaces.

Hago esto para asegurarme de que ni yo ni mis desarrolladores estén tentados de hacer referencia a las implementaciones directamente.

Específicamente, cuando crea un par interfaz / implementador, y no hay una preocupación primordial de la organización (como que la interfaz debe ir en un ensamblaje diferente, es decir, como lo recomienda la arquitectura s #), ¿tiene una forma predeterminada de organizarlos en su espacio de nombres / esquema de nombres?

Obviamente, esta es una pregunta basada más en la opinión, pero creo que algunas personas han pensado más sobre esto y todos podemos beneficiarnos de sus conclusiones.

La respuesta depende de tus intenciones.

Si pretende que el consumidor de sus espacios de nombres utilice las interfaces sobre las implementaciones concretas, le recomendaría tener sus interfaces en el espacio de nombres de nivel superior con las implementaciones en un espacio de nombres secundario
Si el consumidor va a usar ambos, tenerlos en el mismo espacio de nombres.
Si la interfaz es para uso predominantemente especializado, como crear nuevas implementaciones, considere tenerlas en un espacio de nombres secundario, como Design o ComponentModel.

Estoy seguro de que también hay otras opciones, pero como con la mayoría de los problemas del espacio de nombres, todo se reduce a los casos de uso del proyecto y las clases e interfaces que contiene.

Lo que generalmente hago es crear un espacio de nombres de Interfaces en un nivel alto en mi jerarquía y poner todas las interfaces allí (no me molesto en anidar otros espacios de nombres porque terminaría con muchos espacios de nombres que contienen solo una interfaz).

Esta es la forma en que lo hice en el pasado y no he tenido muchos problemas con eso, aunque es cierto que podría confundir a los demás al sentarse con mis proyectos. Tengo mucha curiosidad por ver lo que otras personas hacen.

Por lo general, mantengo la interfaz en el mismo espacio de nombres que los tipos concretos.

Pero, esa es solo mi opinión, y el diseño del espacio de nombres es muy subjetivo.

En realidad, no se gana nada moviendo uno o dos tipos del espacio de nombres principal, pero sí se agrega el requisito para una declaración de uso adicional.

Prefiero mantener mis interfaces y clases de implementación en el mismo espacio de nombres. Cuando es posible, ofrezco a las clases de implementación visibilidad interna y proporciono una fábrica (generalmente en la forma de un método de fábrica estático que delega en una clase de trabajadores, con un método interno que permite que una unidad pruebe en un ensamblado amigo para sustituir a un trabajador diferente produce stubs). Por supuesto, si la clase concreta debe ser pública, por ejemplo, si se trata de una clase base abstracta, está bien; No veo ninguna razón para poner un ABC en su propio espacio de nombres.

En una nota lateral, no me gusta mucho la convención de .NET de los nombres de la interfaz previa con la letra ''I.'' Lo que los modelos de interfaz (I) Foo no son un ifoo , es simplemente un foo . Entonces, ¿por qué no puedo simplemente llamarlo Foo? Luego, nombro las clases de implementación específicamente, por ejemplo, AbstractFoo, MemoryOptimizedFoo, SimpleFoo, StubFoo, etc.

Separe las interfaces de alguna manera (proyectos en Eclipse, etc.) para que sea fácil implementar solo las interfaces. Esto le permite proporcionar su API externa sin proporcionar implementaciones. Esto permite que los proyectos dependientes se construyan con un mínimo de elementos externos. Obviamente, esto se aplica más a proyectos más grandes, pero el concepto es bueno en todos los casos.

Normalmente los separé en dos asambleas separadas. Una de las razones habituales para una interfaz es tener una serie de objetos con el mismo subsistema de su software. Por ejemplo, tengo todos mis informes implementando las interfaces IReport. IReport se utiliza no solo para imprimir, sino también para obtener una vista previa y seleccionar opciones individuales para cada informe. Finalmente tengo una colección de IReport para usar en el diálogo donde el usuario selecciona qué informes (y opciones de configuración) quiere imprimir.

Los informes residen en un ensamblaje separado y el IReport, el motor de vista previa, el motor de impresión, las selecciones de informes residen en su ensamblaje de núcleo respectivo y / o ensamblado de UI.

Si utiliza Factory Class para devolver una lista de informes disponibles en el conjunto de informes, actualizar el software con un nuevo informe se convierte simplemente en una cuestión de copiar el nuevo conjunto de informes sobre el original. Incluso puede usar Reflection API para escanear la lista de ensamblajes de cualquier Factoría de informes y crear su lista de Informes de esa manera.

Puede aplicar estas técnicas a los archivos también. Mi propio software ejecuta una máquina de corte de metal, así que usamos esta idea para las bibliotecas de forma y ajuste que vendemos junto con nuestro software.

Una vez más, las clases que implementan una interfaz central deben residir en un ensamblaje separado para que pueda actualizarlo por separado del resto del software.

ME ODIO cuando encuentro interfaces e implementaciones en el mismo espacio de nombres / ensamblaje. Por favor, no hagas eso, si el proyecto evoluciona, es un dolor en el culo para refactorizar.

Cuando hago referencia a una interfaz, quiero implementarla, no para obtener todas sus implementaciones.

Lo que podría ser admisible es poner la interfaz con su clase de dependencia ( ~~clase que hace referencia a la interfaz~~ )

EDIT: @Josh, simplemente leí la última oración mía, ¡es confuso! por supuesto, tanto la clase de dependencia como la que la implementa hacen referencia a la interfaz. Para aclararme, daré ejemplos:

Aceptable:

Implementación de Interface +:

namespace A; Interface IMyInterface { void MyMethod(); } namespace A; Interface MyDependentClass { private IMyInterface inject; public MyDependentClass(IMyInterface inject) { this.inject = inject; } public void DoJob() { //Bla bla inject.MyMethod(); } }

Clase de implementación:

namespace B; Interface MyImplementing : IMyInterface { public void MyMethod() { Console.WriteLine("hello world"); } }

INACEPTABLE:

namespace A; Interface IMyInterface { void MyMethod(); } namespace A; Interface MyImplementing : IMyInterface { public void MyMethod() { Console.WriteLine("hello world"); } }

¡Y POR FAVOR NO CREA un proyecto / basura para sus interfaces! ejemplo: ShittyProject.Interfaces. ¡Te has perdido el punto!

Imagine que creó una DLL reservada para sus interfaces (200 MB). Si tuviera que agregar una sola interfaz con dos líneas de códigos, ¡sus usuarios deberán actualizar 200 MB solo por dos firmas tontas!

Doy mi propia experiencia que está en contra de otras respuestas.

Tiendo a poner todas mis interfaces en el paquete al que pertenecen. Esto garantiza que, si muevo un paquete en otro proyecto, tengo todo lo necesario para ejecutar el paquete sin ningún cambio.

Para mí, todas las funciones de ayuda y las funciones de operador que forman parte de la funcionalidad de una clase deben ir al mismo espacio de nombres que el de la clase, ya que forman parte de la API pública de ese espacio de nombres.

Si tiene implementaciones comunes que comparten la misma interfaz en diferentes paquetes, probablemente necesite refactorizar su proyecto.

A veces veo que hay muchas interfaces en un proyecto que se pueden convertir en una implementación abstracta en lugar de una interfaz.

Por lo tanto, pregúntese si realmente está modelando un tipo o una estructura.