c＃扩展方法 – 设计模式
我想知道C＃扩展方法是否基于任何现有的设计模式。
设计模式只是一个众所周知的范例，即“当你想要实现X，做Y”时。 面向对象语言（如C＃）中众所周知的范例是“当您想要对对象的状态进行操作时，在其实例上调用方法”。
但是，在创建扩展方法之前，您无法在无法添加实现的对象实例上调用自己的方法（例如，接口因为它们不能实现，或者因为它们已经编译而没有库类）。 扩展方法通过允许您在对象的实例上创建看似可调用的方法来填充此间隙，同时在对象的实现外部定义。
所以是的，可以说扩展方法基于这种非常简单的设计模式，使得作用于对象状态的方法看起来可以从它的实例中调用。
扩展方法可以被视为访客模式的替代。 还建议它们可以用作适配器 。
通常，语言的发展使得设计模式的需求变得不那么必要。 举个例子，Lisp不需要设计模式，因为一切都是用语言构建的。 所以正确的问题是，扩展方法取代了哪些设计模式？
不，这只是一种语言function。
它们不是基于现有的设计模式。 当这个“特征”首次在Delphi中引入时，名为“类助手” ，Borland甚至警告用户不要使用它们。 他们被认为是一个黑客 ，但现在灰尘已经解决他们找到了自己的地方。
像其他一切一样，在适当时使用。
不，他们不是，因为他们只是语法糖。
最接近的规范设计模式可能是Decorator模式 。
不，但扩展方法非常适合实现某些GoF设计模式（例如Prototype）。
当然，如果要实现某些设计模式，可以使用C＃扩展方法。 例如，在C＃中模拟mixins。
我不会将扩展方法标记为任何常见的设计模式，但它可以用于实现Decorator和Adapter等模式。
扩展方法的最佳匹配设计模式是Facade模式。 我的理由：我们通常使用扩展方法不引入目标类责任之外的新function，而是使用现有目标类使用进行简化。 因为简化目标类使用是Facade模式关注，所以可以使用Facade模式替代地实现扩展方法。 扩展和unit testing扩展方法存在一些问题。 所以我认为实现Facade模式是一种更好的方法来反对使用扩展方法。 但是，可以实现一些包装外观接口的扩展方法，以便为客户端代码提供编码工具。