Meilleures pratiques pour la création de bibliothèques utilisant des espaces de noms .NET

Question

Est-ce une mauvaise pratique d'écrire une bibliothèque qui définit une interface dépendant d'une autre bibliothèque?

Je sais que le couplage serré est mauvais, mais cela s'applique-t-il quand on utilise les classes .NET? Par exemple, dans .NET, si j'ai une bibliothèque qui renvoie un objet Color, cela forcerait une dépendance sur System.Drawing sur tout ce qui utilise ma bibliothèque. Serais-je mieux de créer ma propre classe de couleur dans ma bibliothèque?

Answer 1

Je distingue entre Volatile et stables dépendances. En général, Color ressemble à une dépendance stable car il est déjà dans la BCL, il est de nature déterministe et n'implique aucune communication hors processus intensive en ressources, et ne dépend pas non plus d'une configuration particulière. de son environnement d'exécution. La seule chose à prendre en compte ici est que lorsqu'il s'agit de Color, il y en a plus d'une dans la BCL, alors assurez-vous de ne cibler que les applications Windows Forms avec votre API, car WPF a sa propre définition de couleur. Si vous avez juste besoin de la couleur pour peindre des parties de l'interface utilisateur dans une certaine couleur, alors la classe de couleur intégrée est probablement bonne, mais si Couleur est un concept principal dans votre modèle de domaine, et que vous devez cibler différents UI (WPF, Windows Forms, Web) vous serait probablement mieux en définissant votre propre abstraction.

Dans un cas plus avancé, vous pourriez créer des adaptateurs et des mappeurs autour de votre abstraction pour combler le fossé entre l'abstraction et les classes de couleurs concrètes.

Answer 2

S'il s'agit d'une bibliothèque .NET standard, je ne m'inquiéterais pas. Aucune raison de mapper d'une classe à l'autre ... et si System.Color changeait dans la prochaine version .NET? Vous devrez également modifier votre code de cartographie, et éventuellement devoir détecter la version et la carte en conséquence. C'est une vraie douleur.

Answer 3

Avec toutes mes bibliothèques, je retourne des objets qui dépendent uniquement de choses dans la bibliothèque. Je voudrais me demander pourquoi j'écrivais une bibliothèque qui dépendrait d'un autre espace de noms qui n'était pas implicite. Cela semble aller à l'encontre de tout le concept de "Encapsulation". Donc, juste en partant de mon propre raisonnement et de ma connaissance de la POO, je dirais que vous êtes sur la bonne voie en retournant votre propre objet non dépendant.

Answer 4

Vous posez une excellente question. La réponse est: cela dépend. Dans le cas de bibliothèques standard qui seront toujours disponibles, alors c'est bien; la bibliothèque de base référence différents .DLL tout le temps.

Dans le cas d'une bibliothèque tierce, vous rencontrez des problèmes. Ce n'est pas toujours une bonne idée de rouler la vôtre si quelque chose d'autre fait ce que vous voulez, mais alors vous avez une dépendance à une autre bibliothèque, ce qui est un problème logistique pour les utilisateurs.

Il n'y a pas de bonne réponse ici, il vous suffit de choisir ce qui est le plus logique pour votre projet. Essayez de vous découpler autant que possible, oui, mais parfois vous devez juste câliner et faire le travail.

Answer 5

Cela dépend de votre utilisation de la classe.

Si vous avez besoin d'obtenir une instance de la classe System Color à partir d'une instance de votre classe Color (par exemple si vous dessinez dans un formulaire Windows), il est préférable d'utiliser la classe System. effort d'avoir à convertir entre les deux types et vous donne l'avantage de pouvoir utiliser gratuitement toutes les "Caractéristiques" de la classe Color (telles que les constantes intégrées pour "Red", "Black", "Green", etc. Si d'un autre côté, vous travaillez simplement avec des valeurs RVB arbitraires (peut-être pour des calculs scientifiques) et jamais besoin de convertir en une instance de System.Color, alors il serait logique de créer votre propre classe

Selon toute vraisemblance, il vaut mieux utiliser la classe System.Color - oui l'encapsulation et tout ce qui est une bonne idée, mais pas au prix de vous faire gagner énormément de temps!

Answer 6

Vous ne devriez pas vous soucier d'utiliser quoi que ce soit dans la bibliothèque principale .NET. Vous n'irez pas très loin en écrivant une DLL sans elle. Le seul endroit où il faut faire attention est l'espace de noms System.Web car je crois que .NET 4 a un programme d'installation de profil client qui signifie que si vous utilisez ce programme, il installera uniquement les choses qui seront utilisées sur un client. Personnellement, je pense que c'est une mauvaise idée sur Microsoft Part car cela ne fait qu'ajouter une complication inutile pour économiser un peu de temps de téléchargement.