编写一个定义依赖于另一个库的接口的库是一种不好的做法吗?
我知道紧密耦合不好,但是在使用 .NET 类时这仍然适用吗?
例如,在 .NET 中,如果我有一个返回 Color 对象的库,它将强制使用我的库的任何内容都依赖于 System.Drawing。在我的库中创建自己的颜色类型类会更好吗?
我区分Volatile http://blogs.msdn.com/ploeh/archive/2006/08/24/718828.aspx and 稳定的依赖关系.
一般来说,Color 看起来像一个稳定的依赖项,因为它已经在 BCL 中,它本质上是确定性的,不涉及任何资源密集型的进程外通信,而且它也不依赖于其运行的特定设置。时间环境。
这里唯一需要考虑的是,当谈到颜色时,BCL 中有多个这样的类,因此请确保您的 API 确实只针对 Windows 窗体应用程序,因为 WPF 有自己的颜色定义。
如果您只需要 Color 以某种颜色绘制 UI 的各个部分,那么内置 Color 类可能就可以了,但是如果 Color 是域模型中的主要概念,并且您需要针对不同的 UI(WPF、 Windows 窗体、Web)通过定义自己的抽象可能会更好。
在这种更高级的情况下,您可以随后围绕抽象创建适配器和映射器,以弥合抽象和具体 Color 类之间的差距。
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)