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