类和扩展方法容器类在同一个命名空间。优点是什么？ [英] Class and extension method container class in same namespace. What is the benefit?

问题描述

我试图 NBuilder 在我的单元测试。一个优秀的图书馆。然而，我无法解释的类和接口的结构如下：

I was trying NBuilder in my unit test. An excellent library. However, I could not explain the following structure of classes and interfaces.

• 在 FizzWare.NBuilder 命名空间：

• ISingleObjectBuilder


• SingleObjectBuilderExtensions

• ISingleObjectBuilder
• SingleObjectBuilderExtensions

在 FizzWare.NBuilder.Implementation

• IObjectBuilder`


• ObjectBuilder的

• IObjectBuilder`
• ObjectBuilder

SingleObjectBuilderExtensions 简直就是 IObjectBuilder 。

客户端代码通常应该使用一个类命名生成器有，给你一个静态方法 ISingleObjectBuilder 。你永远需要实例任何类的客户端代码。

The client code should usually use a class named Builder which has a static method that gives you ISingleObjectBuilder. You never need to instantiate any of the classes in client code.

现在，我不明白的点 SingleObjectBuilderExtensions 。它是否给任何类型的设计的好处？为什么不是方法是直接在 ISingleObjectBuilder 特别是当这两个接口都在同一个命名空间。

Now, I dont get the point of the SingleObjectBuilderExtensions. Does it give any kind of design benefit? Why not the methods are directly in ISingleObjectBuilder specially when the two interfaces are in same namespace.

推荐答案

ISingleObjectBuilder 是一个接口;接口不能提供实现。这将意味着 ISingleObjectBuilder 的每一个实施将需要提供的落实。

ISingleObjectBuilder is an interface; interfaces cannot provide implementation. That would mean that every implementation of ISingleObjectBuilder would need to provide the implementation.

然而，在许多情况下，方法有一个预定义的行为，只需要访问界面的其他成员（即只是 ISingleObjectBuilder 成员），所以没有益处使每一个执行提供这种

However, in many cases, a method has a pre-defined behaviour, and just needs access to other members of the interface (i.e. just members of ISingleObjectBuilder), so there is no benefit in making each implementation provide this.

此外，这不是一个好主意的添加多个成员的到现有的接口，因为这将是对现有的所有重大更改。实施

Additionally, it is not a good idea to add more members to an existing interface, since that would be a breaking change for all existing implementations.

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

Extension methods solve both of these issues:

1. 扩展方法将用于 ISingleObjectBuilder


2. 它不会改变现有的API，因此所有现有的实现将继续有效<所有实施工作/ LI>
   

1. the extension method will work for all implementations of ISingleObjectBuilder
2. it doesn't change the existing API, so all existing implementations will continue to be valid

有它在同一个命名空间只是带来方便。这是任何代码使用的是有可能的赌注 ISingleObjectBuilder 中已经有使用指令导入的命名空间;因此，大多数代码将的已的看到IDE扩展方法只需按。在IDE中。

Having it in the same namespace simply makes it convenient. It is a likely bet that any code using ISingleObjectBuilder already has a using directive importing that namespace; therefore, most code will already see the extension method in the IDE simply by pressing . in the IDE.

要添加一个具体的例子，LINQ到对象上作品的IEnumerable< T> 。有许多的的IEnumerable< T> 实现。如果每个人有自己写的第一（...）， FirstOrDefault（...），任何（...），选择（...）等方法，这将是一个的巨大的的负担 - 机器人将提供无以效益为实现将在大多数情况下几乎是相同的。 。此外，该装配在接口追溯将是灾难性的。

To add a concrete example, LINQ-to-Objects works on IEnumerable<T>. There are lots of IEnumerable<T> implementations. If each of them had to write their own First(...), FirstOrDefault(...), Any(...), Select(...) etc methods, that would be a huge burden - bot would provide no benefit as the implementations would be pretty much identical in most cases. Additionally, fitting this onto the interface retrospectively would have been disastrous.

作为一个方面说明：每类的方法版本的总是优先于扩展方法，因此如果（在LINQ到对象的情况下），你有一个类型实现的IEnumerable< T> （对于某些 T ），以及该类型有一个。首先（）实例方法，那么：

As a side note: per-type versions of a method always take precedence over extension methods, so if (in the case of LINQ-to-Objects) you have a type that implements IEnumerable<T> (for some T), and that type has a .First() instance method, then:

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

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

will use your version, not the extension methods.

这篇关于类和扩展方法容器类在同一个命名空间。优点是什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！