C# 类和扩展方法容器类位于同一命名空间中。好处是什么？

我试着做单元测试。优秀的图书馆。但是，我无法解释类和接口的以下结构

• 在

  FizzWare.NBuilder

  命名空间中：

  • ISingleObjectBuilder

  • SingleObjectBuilderExtensions

• 在

  FizzWare.NBuilder.Implementation中
  
  
  IObjectBuilder`
  ObjectBuilder
  

• SingleObjectBuilderExtensions

  只是

  IOObjectBuilder

  上的包装器

• 客户机代码通常应该使用名为

  Builder

  的类，该类有一个静态方法，可以为您提供

  ISingleObjectBuilder

  。您永远不需要在客户机代码中实例化任何类

---

现在，我不明白

SingleObjectBuilderExtensions

的要点。它会给设计带来什么好处吗？为什么方法不直接在

ISingleObjectBuilder

中，特别是当两个接口在同一名称空间中时。

扩展方法只是语法上的糖。它们是正常的静态方法，用于处理它们“扩展”公开的类的公共数据

似乎不需要这些扩展方法来处理私有字段，它还提供了使用接口而不是抽象类的能力。每个人都知道接口比抽象类更好

---

两者位于同一名称空间中的原因是避免仅为了使用扩展方法而声明新名称空间。有多少次您尝试使用LINQ，却发现intellisense中没有任何方法，或者代码没有编译。原因是没有系统。包含Linq命名空间。

ISingleObjectBuilder

是一个接口；接口不能提供实现。这意味着

ISingleObjectBuilder

的每个实现都需要提供实现

但是，在许多情况下，方法具有预定义的行为，并且只需要访问接口的其他成员（即，

ISingleObjectBuilder

的成员），因此让每个实现都提供此功能没有任何好处

此外，向现有接口添加更多成员不是一个好主意，因为这将是对所有现有实现的突破性更改

扩展方法解决了这两个问题：

扩展方法适用于

ISingleObjectBuilder的所有实现

它不会改变现有的API，因此所有现有的实现都将继续有效

将它放在同一名称空间中只会使它更方便。很可能任何使用

ISingleObjectBuilder

的代码都已经有一个

using

指令导入该名称空间；因此，大多数代码只需在IDE中按

，就可以在IDE中看到扩展方法

为了添加一个具体的示例，LINQ To Objects在

IEnumerable

上工作。有大量的

IEnumerable

实现。如果他们每个人都必须编写自己的

First（…）

，

First或default（…）

，

任何（…）

，

选择（…）

等方法，这将是一个巨大的负担-bot将不会提供任何好处，因为在大多数情况下，实现几乎是相同的。此外，回顾性地将其安装到接口上将是灾难性的

作为旁注：每个类型方法的版本总是优先于扩展方法，因此如果（在LINQ to对象的情况下）您有一个实现

IEnumerable

（对于某些

T

）的类型，并且该类型有一个

。首先（）

实例方法，然后：

YourType foo = ...
var first = foo.First();

---

将使用您的版本，而不是扩展方法。

LINQ toObjects类比解释了一切：）谢谢。马克，您能检查一下吗