Prácticas recomendadas para crear bibliotecas que usan espacios de nombres .NET

Question

¿Es una mala práctica escribir una biblioteca que defina una interfaz dependiente de otra biblioteca?

Sé que el acoplamiento cerrado es malo, pero ¿esto todavía se aplica cuando se utilizan clases .NET?

Por ejemplo, en .NET, si tengo una biblioteca que devuelve un objeto Color, forzaría una dependencia en System.Drawing en cualquier cosa que use mi biblioteca. ¿Sería mejor crear mi propia clase Color-type dentro de mi biblioteca?

Answer 1

que distinguir entre Volatile y Dependencias estables.

En general, el Color parece una Dependencia Estable porque ya está en el BCL, es de naturaleza determinista y no implica ninguna comunicación fuera de proceso que requiera muchos recursos, y tampoco depende de una configuración particular de su entorno de tiempo de ejecución.

La única consideración aquí es que cuando se trata de Color, hay más de una clase de este tipo en el BCL, así que asegúrese de tener como objetivo solo las aplicaciones de Windows Forms con su API, porque WPF tiene su propia definición de color

Si solo necesita el color para pintar partes de la IU en un color determinado, entonces la clase de Color incorporada probablemente sea adecuada, pero si el Color es un concepto principal en su Modelo de dominio, y debe apuntar a diferentes UI (WPF, Windows Forms, Web) probablemente sería mejor definiendo su propia abstracción.

En un caso tan avanzado, podría crear adaptadores y correlacionadores alrededor de su abstracción para cerrar la brecha entre la abstracción y las clases de colores concretas.

Answer 2

Si se trata de una biblioteca .NET estándar, no me preocuparía. No hay razón para mapear de una clase a otra ... ¿Qué pasa si System.Color cambió en la próxima versión de .NET? Tendría que cambiar su código de mapeo también, y posiblemente tenga que detectar la versión y el mapa en consecuencia. Eso es un verdadero dolor

Answer 3

Con todas mis bibliotecas, devuelvo objetos que dependen solo de elementos de la biblioteca.

Me preguntaba por qué estaba escribiendo una biblioteca que dependería de otro espacio de nombres que no estuviera implícito. Parece ir en contra de todo el concepto de "Encapsulación".

Por lo tanto, al salirse de mi propio razonamiento y conocimiento de OOP, diría que está en el camino correcto con la devolución de su propio objeto no dependiente.

Answer 4

Usted plantea una excelente pregunta. La respuesta es, depende. En el caso de las bibliotecas estándar que siempre estarán disponibles, está bien; la biblioteca central hace referencia a diferentes .DLL todo el tiempo.

En el caso de una biblioteca de terceros, tiene problemas. No siempre es una buena idea lanzar la suya si algo más hace lo que desea, pero luego tiene una dependencia en otra biblioteca, que es un problema logístico para los usuarios.

No hay una respuesta correcta aquí, solo tiene que ir con lo que tenga más sentido para su proyecto. Intenta desacoplar tanto como sea posible, sí, pero a veces solo tienes que acurrucarte y hacer el trabajo.

Answer 5

Depende de su uso de la clase.

Si alguna vez necesita obtener una instancia de la clase de color del sistema de una instancia de su clase de Color (por ejemplo, si dibuja en un formulario de Windows) sería mejor usar la clase de Sistema - le ahorra el esfuerzo de tener que convertir entre los dos tipos y le da la ventaja de poder utilizar todas las "Características" de la clase Color de forma gratuita (como las constantes integradas para "Rojo", "Negro", "Verde", etc.) ..

Si por el contrario simplemente está trabajando con valores arbitrarios RGB (quizá para cálculos científicos) y nunca se necesidad de convertir a una instancia de System.Color, entonces podría tener sentido para crear su propia clase

Con toda probabilidad, será mejor que use la clase System.Color - sí, encapsulación y todo eso es una buena idea, ¡pero no a costa de ahorrarle grandes cantidades de tiempo!

Answer 6

No debe preocuparse por usar nada en la biblioteca principal de .NET. No llegarías muy lejos al escribir una DLL sin eso. El único lugar posible para tener cuidado al respecto es el espacio de nombres de System.Web, como creo .NET 4 tiene un instalador de perfil de cliente que básicamente significa que si usa este instalador, solo instalará las cosas que se espera que se usen en un cliente. Personalmente creo que es una mala idea para la parte de Microsoft, ya que solo agrega una complicación innecesaria para ahorrar una pequeña cantidad de tiempo de descarga.