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

Question

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

.netdependencieslibrariescoupling

11

编写定义依赖于另一个库的接口的库是否是不良实践？

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

例如，在.NET中，如果我有一个返回Color对象的库，它将强制依赖于System.Drawing上使用我的库的任何内容。我最好在我的库内创建自己的颜色类型类吗？

- DanDan

6个回答

5

如果这是一个标准的.NET库，那么不需要担心。没有必要从一个类映射到另一个类……如果System.Color在下一个.NET版本中发生了更改怎么办？您还需要更改映射代码，并可能需要检测版本并相应地进行映射。这真的很麻烦。

- Beep beep

2

BCL代码在版本之间往往不会改变，但另一方面，新的颜色类型可能会出现 - 它们已经出现了：如果您依赖于System.Drawing.Color，则将无法在WPF中使用您的API。 - Mark Seemann

2

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

如果我编写的库需要依赖另一个不是默认命名空间的命名空间，我就会问自己为什么要这样做。这似乎违反了“封装”的整体概念。

因此，基于我的推理和面向对象编程的知识，我认为你通过返回自己的非依赖对象已经做得很好了。

- Pete H.

我认为在mscorlib中使用命名空间是可以接受的；除此之外，这个原则是正确的。 - Jeremy McGee

我也喜欢你的原则，我会遵循它。 - DanDan

1

你提出了一个很好的问题。答案是：这取决于情况。对于始终可用的标准库，那就没问题；核心库引用不同的.DLL文件。

对于第三方库，你会遇到问题。如果有其他库可以满足你的需求，自己编写可能并不总是一个好主意，但这样你就依赖于另一个库，这对用户来说是一个后勤问题。

这里没有正确的答案，你只需要选择最适合你项目的方案。尽可能地解耦是好的，但有时你必须要亲自动手完成任务。

- Randolpho

呵呵，我喜欢这个说法：“你只需要拥抱它，完成工作就行了”。在这种情况下，由于Color类相对不重要，我觉得自己写一个会更好。我看到更复杂的情况会带来麻烦。 - DanDan

1

这取决于你对类的使用方式。

如果你需要从你的Color类的实例中获取系统Color类的实例（例如，如果你要绘制到Windows窗体），那么最好使用System类 - 这样可以省去你在两种类型之间转换的麻烦，并且可以免费使用Color类的所有“特性”（例如内置常量“Red”，“Black”，“Green”等）。

另一方面，如果你只是处理任意RGB值（也许用于科学计算）并且永远不需要转换为System.Color的实例，则创建自己的类可能是有意义的。

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

- Justin

我99%肯定不需要使用内置常量，所以在这种情况下，我认为自己动手会更好。谢谢你的建议。 - DanDan

1

你不用担心使用.NET核心库中的任何内容。如果不使用它，您无法在编写DLL时取得很大进展。唯一需要小心的可能是System.Web命名空间，因为我认为.NET 4有一个客户端配置文件安装程序，这基本上意味着如果您使用此安装程序，它只会安装预计在客户端上使用的东西。我个人认为这是微软的一个坏主意，因为它只是为了节省少量下载时间而增加了不必要的复杂性。

- PeteT

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Mark Seemann · Accepted Answer

我将Volatile和稳定依赖项区分开来。

通常情况下，Color看起来像是一个稳定的依赖项，因为它已经在BCL中了，它的性质是确定的，不涉及任何资源密集型的进程外通信，也不依赖于运行时环境的特定设置。

唯一需要考虑的是，当涉及到Color时，在BCL中有多个这样的类，所以请确保您真的只想针对Windows Forms应用程序使用您的API，因为WPF有自己的Color定义。

如果您只需要颜色来绘制UI的某些部分，则内置的Color类可能很好，但如果Color是您域模型中的主要概念，并且您需要针对不同的UI（WPF、Windows Forms、Web），那么最好定义自己的抽象。

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