Las mejores prácticas para la creación de bibliotecas que utilizan espacios de nombres de .NET

Question

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

Sé estrecho acoplamiento es malo, pero esto todavía se aplica cuando el uso de clases de .NET?

Por ejemplo, en .NET, si tengo una biblioteca que devuelve un objeto de color, ya que obligaría a una dependencia en System.Drawing en cualquier cosa que utiliza mi biblioteca. ¿Sería mejor crear mi propia clase-Tipo de color dentro de mi biblioteca?

Answer 1

distingo entre volátil y dependencias estables .

En general, en color se parece a una dependencia estable porque ya está en el BCL, que es de naturaleza determinista y no implica ninguna fuera de la comunicación proceso que consume muchos recursos, y tampoco depende de un determinado establecimiento de su entorno de tiempo de ejecución.

La única consideración es que cuando se trata de color, hay más de una clase en el BCL, así que asegúrese de que usted realmente quiere decir que lo hagan solo aplicaciones de Windows Forms con su API, porque WPF tiene su propia definición de color.

Si sólo necesita el color para pintar partes de la interfaz de usuario en un determinado color, entonces la clase de color incorporado es probablemente muy bien, pero si el color es un concepto principal en su modelo de dominio, y hay que dirigirse a diferentes interfaces de usuario (Formas de WPF, Windows, web) que probablemente sería mejor del definiendo su propia abstracción.

En tal caso más avanzado, que posteriormente podría crear adaptadores y asignadores alrededor de su abstracción para cerrar la brecha entre la abstracción y las clases de color concreto.

Answer 2

Si se trata de una biblioteca estándar de .NET, yo no preocuparse por ello. No hay razón para el mapa de una clase a otra ... ¿y si System.Color cambió en la próxima versión .NET? Habría que cambiar el código de mapeo también, y posiblemente tener para detectar y mapear la versión en consecuencia. Eso es un verdadero dolor de cabeza.

Answer 3

Con todos mis bibliotecas, vuelvo objetos que dependen solamente de las cosas en la biblioteca.

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

Así que sólo por ir fuera de mi propio razonamiento y el conocimiento de programación orientada a objetos, diría que está en el camino correcto con la devolución de su propio objeto no dependiente.

Answer 4

Se plantean una excelente pregunta. La respuesta es, depende. En el caso de las bibliotecas estándar que siempre estarán disponibles, entonces está bien; las referencias de biblioteca núcleo diferentes .DLLs todo el tiempo.

En el caso de una biblioteca de terceros que tenga problemas. No siempre es una buena idea para rodar su propia si algo más hace lo que quiere, pero entonces usted tiene una dependencia de otra biblioteca, que es un problema logístico para los usuarios.

No hay una respuesta aquí, sólo hay que ir con lo que tiene más sentido para su proyecto. Intenta desacoplar la medida de lo posible, sí, pero a veces sólo tiene que abrazar y hacer el trabajo.

Answer 5

Depende de su uso de la clase.

Si alguna vez necesita para obtener una instancia de la clase Color sistema desde una instancia de la clase Color (por ejemplo, si se dibuja a una forma de ventanas), entonces sería mejor utilizar la clase System - que 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 de color de forma gratuita (como el construido en constantes para "rojo", "Negro", "verde", etc .. .

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

Lo más probable es que es mejor usar la clase System.Color - sí encapsulación y todo lo que es una buena idea, sin embargo no a expensas de que le ahorra enormes cantidades de tiempo

!

Answer 6

Usted no debe preocuparse sobre el uso de cualquier cosa en la biblioteca central .NET. No se puede obtener muy lejos en escribir una DLL sin ella. El único lugar posiblemente a tener cuidado alrededor de ella es el espacio de nombres System.Web como creo .NET 4 tiene un instalador perfil de cliente que básicamente significa que si se utiliza este instalador que sólo se instalará cosas que se prevé utilizar en un cliente. Yo personalmente creo que es una mala idea por parte de Microsoft, ya que sólo se suma complicación no-necesario para salvar una pequeña cantidad de tiempo de descarga.