logo标签列表

C# 扩展方法 - 设计模式

c#design-patternsextension-methods
10

我想知道C#扩展方法是否基于任何现有的设计模式。

不要过度使用扩展方法，请参考Eric Lippert博客中的“foreach V's ForEach”一文。http://blogs.msdn.com/ericlippert/archive/2009/05/18/foreach-vs-foreach.aspx - Binary Worrier
10个回答
11

设计模式是一种众所周知的范例，即“当您想要实现X时，请执行Y”。在面向对象语言中（例如C#），一个众所周知的范例是“当您想要对对象的状态进行操作时，请调用其实例上的方法”。

然而，在扩展方法被创建之前，您不能在无法添加实现的对象实例上调用自己的方法（例如接口因为它们不能有实现，或库类因为它们已经编译）。扩展方法通过允许您创建外部于对象实现的方法来填补这个空白。

因此，可以说扩展方法基于这种非常简单的设计模式，即使在外部定义，也可以使作用于对象状态的方法在对象实例上可调用。

这不是类似于装饰器模式但具有不同的结构吗？ - Narshe
8
扩展方法可以被视为访问者模式的替代品。它们也被提议用作适配器。一般来说，语言的发展使得设计模式的需求变得不那么必要。例如，有一句话说Lisp不需要设计模式，因为所有东西都内置在语言中。因此，正确的问题是，扩展方法替换了哪些设计模式？
1
更准确地说，(好的)编程语言倾向于演化以简化流行设计模式的使用。同时请注意，您永远无法摆脱使用设计模式，每个设计都是某种设计模式，设计模式的语言只是一种形式化这个想法并促进某些广为人知和经过测试的模式的使用的方式(就像拱门或扶壁是建筑学中一个众所周知的设计模式一样)。 - Wedge
5
不，这只是一种语言特性。
它可以是两者兼备的。例如，委托是C#语言的一种特性，可以实现发布-订阅模式。 - Anthony
2
它们不是基于现有的设计模式。当这个“特性”首次在Delphi中引入，以'类助手'的名称出现时，Borland甚至警告用户远离它们。它们被认为是一种小技巧，但现在尘埃落定，它们找到了自己的位置。
像其他一切一样，适当时使用。
2
1
不是，因为它们只是语法糖。
严格地说，扩展方法并不是语法糖。但你可以使用与实例方法相同的语法来调用它们。 - Rune FS
1
如果你不相信我，你可以在谷歌中搜索这个短语：“扩展方法是语法糖”，你会发现数百个链接证明了我的观点。 - Sergey Teplyakov
1
Rune，如果没有这个能力，扩展方法就只是普通的静态方法。“你可以使用与实例方法相同的语法调用它们”的能力是扩展方法唯一的特性，正如你自己所说，这个特性只是语法糖。 - Ilya Kogan
如果我想要自己实现一个扩展，那么它的“酸”语法会是什么样子？ - Narshe
1
不是，但扩展方法非常适合实现某些GoF设计模式（例如原型）。
0

当然，如果您想要实现某些设计模式，可以使用C#扩展方法。例如，在C#中模拟混合。

0
我不会将扩展方法标记为任何常见的设计模式，但它可以用于实现装饰器和适配器等模式。
0
与扩展方法最匹配的设计模式是Facade（外观）模式。 原因：我们通常使用扩展方法不是为了超出目标类职责的新功能，而是简化现有目标类的使用。 因为简化目标类使用是Facade（外观）模式关注的内容，扩展方法可以使用Facade（外观）模式作为替代实现。 在扩展和单元测试扩展方法时存在一些问题。因此，我认为采用Facade（外观）模式是比使用扩展方法更好的方法。 然而，可能会实现一些包装Facade（外观）接口的扩展方法，以为客户端代码提供编码便利。
你能详细阐述一下你的答案并解释原因吗？ - slfan
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接