est-il une mauvaise pratique d'écrire une bibliothèque qui définit une interface dépendante d'une autre bibliothèque?
Je sais que le couplage serré est mauvais, mais cela s'applique-t-il toujours lors de l'utilisation de classes .NET?
Par exemple, dans .NET, si j'ai une bibliothèque qui renvoie un objet de couleur, elle forcerait une dépendance sur le système .Drawing sur tout ce qui utilise ma bibliothèque. Serais-je préférable de créer ma propre classe de type couleur dans ma bibliothèque?
6 Réponses :
Si c'est une bibliothèque standard .NET, je ne m'inquiéterais pas pour ça. Aucune raison de cartographier d'une classe à une autre ... Et si System.color a changé dans la prochaine version .NET? Vous devez également modifier votre code de cartographie et je dois éventuellement détecter la version et la carte en conséquence. C'est une vraie douleur.
Le code BCL a tendance à ne pas modifier entre les versions, mais d'autre part, de nouveaux types de couleurs peuvent apparaître - et ils ont: si vous prenez une dépendance sur le système.Drawing.color, vous aurez fermé votre API dans WPF.
Avec toutes mes bibliothèques, je retourne des objets qui ne dépendent que des choses dans la bibliothèque.
Je me demanderais pourquoi j'écris une bibliothèque qui dépendrait d'un autre espace de noms qui n'était pas implicite. Il semble aller contre l'ensemble du concept "encapsulation".
Alors, simplement en sortant de mon propre raisonnement et de mes connaissances de OOP, je dirais que vous êtes sur la bonne voie en retournant votre propre objet non dépendant.
Je pense qu'il est acceptable de travailler avec des espaces de noms dans MSCorLib; En dehors de cela, le principe est sonore.
J'aime aussi votre principe, je vais le suivre.
Je distingue entre volatile < / strong> et dépendances stables .
En général, la couleur ressemble à une dépendance stable, car elle est déjà dans la BCL, elle est déterministe dans la nature et n'implique pas de communication de processus intensif de ressources et ne s'appuie pas non plus à une installation particulière de son environnement d'exécution.
La seule considération ici est que, lorsqu'il s'agit de couleur, il existe plus d'une classe de ce type dans le BCL, alors assurez-vous que vous voulez vraiment dire que les applications Windows forment des applications Windows 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 d'une certaine couleur, la classe de couleur intégrée est probablement bien, mais si la couleur est un concept principal dans votre modèle de domaine et que vous devez cibler différentes règles de l'UIS. (WPF, Windows Forms, Web) Vous seriez probablement mieux en définissant votre propre abstraction.
Dans un cas aussi avancé, vous pouvez ultérieurement créer des adaptateurs et des mappeurs autour de votre abstraction pour combler l'écart entre l'abstraction et les classes de couleur concrètes.
Excellent lien vers des dépendances volatiles et en général une bonne réponse. +1!
Merci pour cette information, pleine de conseils sur les problèmes que je n'avais même pas envisagés. Je suis sûr que j'aimerais m'éloigner de Winforms à un moment donné.
J'aime ce conseil, cela me rappelle de garder la dépendance de mes cours et de coupler avec le poste de Gus (le principe GUS) que le conseil général semble être "roulant le mien" ". Ce plan d'action est le plus efficace en raison de la classe de couleur triviale. Dans des situations plus complexes avec des dépendances tierces de 3e parties, comme le mentionne Randolpho, ce principe peut être plié, ou la conception de la conception d'une manière ou d'une autre. Merci pour vos messages!
Vous posez une excellente question. La réponse est la suivante: cela dépend. Dans le cas des bibliothèques standard qui seront toujours disponibles, alors c'est bien; La bibliothèque principale références différentes .dlls tout le temps.
Dans le cas d'une bibliothèque tierce partie, vous rencontrez des problèmes. Ce n'est pas toujours une bonne idée de faire rouler votre propre si quelque chose d'autre fait ce que vous voulez, mais vous avez alors une dépendance à une autre bibliothèque, qui est un problème logistique pour les utilisateurs.
Il n'y a pas de bonne réponse ici, il vous suffit d'aller avec ce qui est le plus sens à votre projet. Essayez de découpler autant que possible, oui, mais parfois vous devez juste vous câliner et faire le travail.
Hehe, j'aime le terme "Tu dois juste te câliner et faire le travail". Je pense que dans ce cas, en raison de la fréquence relative de la classe de couleur, je ferai mieux de rouler le mien. Je vois des cas plus compliqués vont apporter des maux de tête.
Cela dépend de votre utilisation de la classe.
Si vous avez besoin d'obtenir une instance de la classe de couleur système à partir d'une instance de votre classe de couleurs (par exemple, si vous dessinez sur un formulaire Windows), il serait préférable d'utiliser la classe système - cela vous permet d'économiser les efforts. D'avoir à convertir entre les deux types et vous donne l'avantage de pouvoir utiliser toutes les "caractéristiques" de la classe de couleur (telles que constantes intégrées pour "rouge", "noir", "vert" .. .
Si d'autre part, 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, il peut être logique de créer votre propre classe.
Dans toutes les probabilités, vous ferez mieux d'utiliser la classe System.color - Oui encapsulation et tout ce qui est une bonne idée, cependant pas au détriment de vous sauver des quantités massives!
Je suis sûr que je suis sûr que je n'aurai pas besoin des constantes intégrées, donc dans ce cas, je pense que je vais mieux rouler le mien. Merci pour votre conseil.
Vous ne devriez pas vous inquiéter d'utiliser quoi que ce soit dans la bibliothèque Core .NET. Vous ne seriez pas très loin d'écrire une dll sans cela. L'espace de noms System.Web tel que je pense que .NET 4 possède un programme d'installation de profil client qui signifie essentiellement si vous utilisez ce programme d'installation, il ne s'agira que d'utiliser les choses à utiliser sur un client. Personnellement, je pense que c'est une mauvaise idée de la part de Microsoft car elle ajoute simplement une complication non nécessaire pour économiser une petite quantité de temps de téléchargement.