创建使用 .NET 命名空间的库的最佳实践答案

【问题标题】：Best practices for creating libraries that use .NET namespaces创建使用 .NET 命名空间的库的最佳实践
【发布时间】：2010-12-26 21:29:37
【问题描述】：

编写一个定义依赖于另一个库的接口的库是不好的做法吗？

我知道紧密耦合不好，但是在使用 .NET 类时这仍然适用吗？

例如，在 .NET 中，如果我有一个返回 Color 对象的库，它会强制 System.Drawing 依赖于使用我的库的任何东西。在我的库中创建自己的 Color-type 类会更好吗？

【问题讨论】：

标签： .net dependencies libraries coupling

【解决方案1】：

我区分 Volatile 和 稳定的依赖关系。

总的来说，Color 看起来像一个稳定的依赖关系，因为它已经在 BCL 中，它本质上是确定性的，不涉及任何资源密集型进程外通信，也不依赖于特定的它的运行时环境。

这里唯一需要考虑的是，当涉及到 Color 时，BCL 中有不止一个这样的类，因此请确保您的 API 仅针对 Windows 窗体应用程序，因为 WPF 有自己的定义颜色。

如果您只需要 Color 以某种颜色绘制 UI 的某些部分，那么内置的 Color 类可能没问题，但如果 Color 是您的 Domain Model 中的主要概念，并且您需要针对不同的 UI （WPF、Windows 窗体、Web）您可能会更好地定义自己的抽象。

在这种更高级的情况下，您随后可以围绕抽象创建适配器和映射器，以弥合抽象和具体 Color 类之间的差距。

【讨论】：

与易失性依赖关系的优秀链接，通常是一个很好的答案。 +1！
感谢您提供这些信息，其中充满了对我从未考虑过的问题的建议。我确定我想在某个时候脱离 WinForms。
我确实喜欢这个建议，它提醒我不要依赖我的课程，再加上 Gus（Gus 原则）的帖子，一般建议似乎是“自己动手”。由于 Color 类是微不足道的，因此此操作过程最有效。正如 Randolpho 所提到的，在具有 3rd 方依赖的更复杂的情况下，这个原则可能不得不改变，或者以某种方式重新考虑设计。感谢您的帖子！

【解决方案2】：

如果它是一个标准的 .NET 库，我不会担心。没有理由从一个类映射到另一个类……如果 System.Color 在下一个 .NET 版本中发生变化怎么办？您还必须更改映射代码，并且可能必须检测版本并相应地映射。真的很痛苦。

【讨论】：

BCL 代码往往不会在版本之间发生变化，但另一方面，可能会出现新的颜色类型——它们有：如果你依赖于 System.Drawing.Color，你就会把自己拒之门外在 WPF 中使用您的 API。

【解决方案3】：

对于我所有的库，我返回的对象仅依赖于库中的内容。

我会问自己为什么要编写一个依赖于另一个非隐式命名空间的库。这似乎与整个“封装”概念背道而驰。

因此，仅根据我自己对 OOP 的推理和知识，我会说您在返回自己的非依赖对象方面走在了正确的轨道上。

【讨论】：

我认为在 mscorlib 中使用命名空间是可以接受的；除此之外，原则是合理的。
我也喜欢你的原则，我会遵守的。

【解决方案4】：

你提出了一个很好的问题。答案是：视情况而定。对于始终可用的标准库，那很好；核心库一直引用不同的 .DLL。

如果是第三方库，您会遇到问题。如果其他东西可以满足您的需求，那么自行推出并不总是一个好主意，但是您依赖于另一个库，这对用户来说是一个后勤问题。

这里没有正确的答案，您只需要选择对您的项目最有意义的方法即可。尝试尽可能地解耦，是的，但有时你只需要拥抱并完成工作。

【讨论】：

呵呵，我喜欢“你只需拥抱并完成工作”这个词。我认为在这种情况下，由于 Color 类的相对琐碎，我最好自己滚动。我看到更复杂的案例会让人头疼。

【解决方案5】：

这取决于你对类的使用。

如果您需要从 Color 类的实例中获取系统 Color 类的实例（例如，如果您绘制到 Windows 窗体），那么最好使用 System 类 - 它可以节省您的工作量必须在两种类型之间进行转换，并为您提供能够免费使用 Color 类的所有“功能”的优势（例如“Red”、“Black”、“Green”等的内置常量。 .

另一方面，如果您只是使用任意 RGB 值（可能用于科学计算）并且从不需要转换为 System.Color 的实例，那么创建您的自己的班级。

您很可能最好使用 System.Color 类 - 是的，封装和所有这些都是一个好主意，但不会以节省大量时间为代价！

【讨论】：

我 99% 确信我不需要内置常量，所以在这种情况下，我认为我最好自己动手。谢谢你的建议。

【解决方案6】：

您不必担心使用 .NET 核心库中的任何内容。没有它，您在编写 DLL 时不会走得太远。唯一可能要小心的地方是 System.Web 命名空间，因为我相信 .NET 4 有一个客户端配置文件安装程序，这基本上意味着如果您使用这个安装程序，它只会安装预期在客户端上使用的东西。我个人认为这对微软来说是个坏主意，因为它只是增加了不必要的复杂性来节省少量的下载时间。

【讨论】：