代码之家 › 专栏 › 技术社区 › MatthewMartin muthu

C中“使用”指令关键字的替代方案?

decoupling coupling c#

5

MatthewMartin muthu · 技术社区 · 15 年前

我刚看完一集,鲍勃·马丁在国家数据中心的节目,他说在页面顶部的C中“使用”指令是不好的,因为它们在组件之间创建/暗示了紧密的耦合。

在不添加项目引用和using语句的情况下,如何使用external.dlls?

我记得V6曾让你通过progid的字符串创建一个对象——我不确定这是我正在寻找的技术,但它是一种不需要项目引用来使用dll的语言的例子。

编辑: Here is a link to the conference . 对不起,我没有确切的报价或分钟在预设,我要去记忆。

5 回复 | 直到 9 年前

1

6

Mark Seemann 15 年前

不好的不是using语句本身,而是如果太多他们当中。

一种陈述,如 using System; 本身很少有问题,但是如果在同一个代码文件中有很多(我想说超过3-6个,取决于哪个),它可能是 紧密耦合指示 .

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

紧密耦合的解决方案是 接口编程 依赖注入(DI)。

用progid做你能从vb中记忆到的事情的方法就是COM。实际上,您使用该progid获取对实现所需接口的实例的引用。缺点是,这只在COM对象被普遍注册时才起作用。还记得DLL地狱吗?

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

2

7

Ash 15 年前

我相信鲍勃·马丁实际上指的是早晚结合。

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

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

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

我想这就是为什么鲍勃说他们是坏人。问题的答案是“这真的很糟糕吗?”是一个非常主观和上下文相关的问题。

一般来说,在设计软件时,组件的去耦合几乎总是一个好的目标。这是因为它允许您在对系统其余部分影响最小的情况下更改系统的某些部分。读过一两本鲍勃·马丁斯的书后,我想这就是他的本领。

3

6

Lucero 15 年前

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

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

看看 Assembly 和 AppDomain 要加载程序集的类,以及 Activator 按名称创建类型实例。

4

2

Darin Dimitrov 15 年前

您可以使用反射:

// Load the assembly
Assembly assembly = Assembly.LoadFrom(@"c:\path\Tools.dll");
// Select a type
Type type = assembly.GetType("Tools.Utility");
// invoke a method on this type
type.InvokeMember("SomeMethod", BindingFlags.Static, null, null, new object[0]);

5

1

kemiller2002 15 年前

你可以通过反思来做你所指的事情。您可以在运行时加载程序集,并通过它进行反射以获取类等,并动态地调用它们。

就个人而言,我不会这样做来避免耦合。对我来说,这是对反射的一种不好的使用,我更愿意将它添加到项目中并引用它,除非有特定的原因不这样做。反射会增加系统开销,而您无法获得编译时安全性的优势。