编写一个定义依赖于另一个库的接口(interface)的库是一种不好的做法吗？
我知道紧密耦合不好，但是在使用 .NET 类时这仍然适用吗？
例如，在 .NET 中，如果我有一个返回 Color 对象的库，它将强制使用我的库的任何内容都依赖于 System.Drawing。在我的库中创建自己的颜色类型类会更好吗？
最佳答案
我区分 Volatile 和稳定的依赖关系。
一般来说，颜色看起来像一个稳定的依赖关系，因为它已经在 BCL 中，它本质上是确定性的，不涉及任何资源密集型的进程外通信，也不依赖于特定的设置它的运行时环境。
这里唯一要考虑的是，当涉及到 Color 时，BCL 中有多个这样的类，因此请确保您的 API 确实只针对 Windows 窗体应用程序，因为 WPF 有自己的定义颜色。
如果您只需要 Color 以某种颜色绘制 UI 的各个部分，那么内置 Color 类可能就可以了，但是如果 Color 是域模型中的主要概念，并且您需要针对不同的 UI (WPF、Windows 窗体、Web)您最好定义自己的抽象。
在这种更高级的情况下，您可以随后围绕抽象创建适配器和映射器，以弥合抽象和具体 Color 类之间的差距。
关于.net - 创建使用 .NET 命名空间的库的最佳实践，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1908739/