编写一个定义依赖于另一个库的接口的库是不好的做法吗？
我知道紧耦合很糟糕，但在使用.NET类时这仍然适用吗？
例如，在.NET中，如果我有一个返回Color对象的库，它将强制在使用我的库的任何东西上依赖System.Drawing。在库中创建自己的Color-type类会更好吗？
答案 0 :(得分：10)
我区分 Volatile 和稳定的依赖关系。
一般来说，Color看起来像一个稳定的依赖，因为它已经在BCL中，它本质上是确定性的，不涉及任何资源密集型的进程外通信，也不依赖于特定的设置它的运行时环境。
这里唯一考虑的是，当涉及到Color时，BCL中有不止一个这样的类，所以请确保你真的只想用你的API定位Windows Forms应用程序，因为WPF有自己的定义颜色。
如果你只需要Color以某种颜色绘制UI的部分内容，那么内置的Color类可能没问题，但是如果Color是域模型中的主要概念，那么你需要定位不同的UI （WPF，Windows Forms，Web）通过定义自己的抽象，你可能会更好。
在这种更高级的情况下，您可以随后围绕抽象创建适配器和映射器，以弥合抽象和具体Color类之间的差距。
答案 1 :(得分：5)
如果它是标准的.NET库，我不会担心它。没有理由从一个类映射到另一个类......如果在下一个.NET版本中System.Color发生了变化怎么办？您还必须更改映射代码，并且可能必须相应地检测版本和映射。这真是一种痛苦。
答案 2 :(得分：2)
对于我的所有库，我返回的对象仅依赖于库中的东西。
我会问自己为什么我要编写一个依赖于另一个非隐式命名空间的库。这似乎与整个“封装”概念背道而驰。
因此，仅仅通过我自己的推理和OOP知识，我会说你正在回归自己的非依赖对象。
答案 3 :(得分：1)
你提出了一个很好的问题。答案是：这取决于。对于总是可用的标准库，那就没关系;核心库一直引用不同的.DLL。
如果是第三方库，则会遇到问题。如果其他东西做了你想要的东西，那么推出自己的东西并不总是一个好主意，但是你依赖另一个库，这对用户来说是一个后勤问题。
这里没有正确的答案，你只需要选择对你的项目最有意义的东西。尝试尽可能地分离，是的，但是有时候你只需要搂抱并完成工作。
答案 4 :(得分：1)
这取决于你对课程的使用情况。
如果您需要从Color类的实例中获取系统Color类的实例（例如，如果您绘制到Windows窗体），那么最好使用System类 - 它可以节省您的工作量必须在两种类型之间进行转换，并且为您提供了能够免费使用Color类的所有“功能”的优势（例如内置常量为“红色”，“黑色”，“绿色”等。
另一方面，如果您只是处理任意RGB值（可能用于科学计算）而从不需要转换为System.Color的实例，那么创建您的可能是有意义的自己的班级。
你很可能最好使用System.Color类 - 是封装，所有这些都是一个好主意，但不能以节省大量时间为代价！
答案 5 :(得分：1)
您不必担心在.NET核心库中使用任何内容。如果没有它，你就不会在编写DLL方面走得太远。唯一可能要小心的地方是System.Web命名空间，因为我相信.NET 4有一个客户端配置文件安装程序，这基本上意味着如果你使用这个安装程序，它只会安装预期在客户端上使用的东西。我个人认为这对微软的部分来说是一个坏主意，因为它只是增加了不必要的复杂性，以节省少量的下载时间。