C#中"using"指令关键字的替代方案？

Question

我刚刚在NDC观看了Bob Martin的一集,他说在页面顶部的C#中使用"using"指令很糟糕,因为它们在组件之间创建/暗示紧密耦合.

在没有添加项目引用和using语句的情况下,有什么方法可以使用外部.dll？

我记得V6曾经让你通过ProgId的字符串创建一个对象 - 我不确定这是我正在寻找的技术,但它是一个不需要项目引用的语言示例DLL.

编辑:这是会议的链接.对不起我在演讲中没有确切的引用或分钟,我记得.

Answer 1

我相信Bob Martin实际上指的是早期与晚期绑定.

在.NET中,后期绑定可以通过反射实现,更具体地说是Activator类,它允许使用文件名或程序集名称在外部程序集中创建类型.

通常,使用指令(而不是using语句)与直接引用外部程序集齐头并进.即.您添加对程序集的引用,然后添加using指令以避免在使用外部类型时需要键入完整的命名空间层次结构.

因此,如果您发现代码在顶部有大量的using指令,则可能直接引用许多其他类型,从而增加代码在这些类型上的耦合/依赖性.

我猜这就是鲍勃把它们称为坏的原因.问题的答案"这真的很糟糕吗？" 是一个非常主观和依赖于背景的人.

但总的来说,组件的分离几乎总是一个很好的目标,旨在设计软件.这是因为它允许您更改系统的各个部分,而对系统的其余部分影响最小.读完一两篇鲍勃·马丁的书后,我希望这就是他所得到的.

Answer 2

using它只是命名空间的快捷方式,它们不是对外部文件的引用.因此,这真的没有意义.

无论如何,人们可以做的是拥有一个接口DLL(只有接口的DLL),这样你就可以动态加载和使用不同的程序集并创建可以转换为众所周知的接口的类型(通过反射).这是放松外部引用的正确方法,同时保持强类型语言和早期绑定的好处.

查看Assembly和AppDomain类以加载程序集,使用Activator按名称创建类型实例.

Answer 3

这不是使用声明本身是坏的 - 如果你得到太多它们就是这样.

像这样的语句using System;本身很少是一个问题,但是如果你在同一个代码文件中有很多(我会说超过3-6,取决于哪些),它可能表示紧耦合.

您也可以将类似的经验法则应用于项目本身的引用数量.

紧耦合的解决方案是对接口和依赖注入(DI)进行编程.

从VB中可以记住的ProgId处理方式就是COM在行动中.本质上,您使用该ProgId来获取对实现所需接口的实例的引用.缺点是这只有在COM对象被普遍注册时才有效.还记得地狱吗？

您仍然可以使用某些类型的DI来应用相同的原则,只是现在接口是.NET类型而没有在IDL中定义,并且您需要某种DI容器来提供具体实现.