blocks|key|4313217|text|一般来说，你不应该通过扩展方法来提供“基础”功能。它们只能用来“扩展”类的功能。如果您可以访问基类代码，并且您尝试实现的功能在逻辑上是继承继承的一部分，那么您应该将其放在抽象类中。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4313218|我的意思是，你可以并不意味着你应该这样做。当普通的老式OO编程不能为您提供合理的解决方案时，最好还是坚持使用好的老式OOP，并使用新的语言特性。|4313219|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

In general, you shouldn't provide "base" functionality through extension methods. They should only be used to "extend" class functionality. If you have access to the base class code, and the functionality you're trying to implement is logically part of the inheritance heirarchy, then you should put it in the abstract class.

My point is, just because you can doesn't mean you should. It's often best just to stick with good old fashioned OOP and use the newer language features when plain old OO programming falls short of providing you a reasonable solution.

blocks|key|4313250|text|它们是语义上不同的操作。例如，多态性可能不像抽象基类那样工作。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4313251|作为一般规则，使用任何语言工具都可以达到设计的目的。扩展方法不是继承的替代品，它们是一种使用(通常)已经可见的接口来扩展类的功能的技术。|4313252|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

They're semantically different operations. For example, polymorphism may not work the way it would with an abstract base class.

As a general rule, use any language tool for what it's designed for. Extension methods aren't a replacement for inheritance, they're a technique to extend the functionality of a class using (typically) it's already-visible interface.

blocks|key|3465871|text|我同意迈克尔的观点。基类应该包含所有的基本功能扩展方法，显然，应该扩展基本功能。在像Ruby这样的动态语言中，通常使用扩展方法来提供附加功能，而不是使用子类。基本上，扩展方法是用子类代替的，而不是用基类代替的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3465872|我见过的唯一例外是，如果您有多个具有不同类层次结构的类型(如winform控件)，您可以为每个类型创建一个子类，所有这些类型都实现和接口，然后扩展该接口，从而为一组不同的控件提供“基本”功能，而无需扩展像Control或Object这样的所有内容。|3465873|编辑:回答你的第二个问题|3465874|我想编译器会帮你捕捉到这一点。|3465875|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

I agree with Michael. Base classes should contain all base functionality Extension methods should, obviously, extend the base functionality. In dynamic languages like Ruby it is often typical to use extension methods to provide addition functionality instead of using subclasses. Basically, extension methods are there to replacing using subclassses, not to replace using base classes.

The only exception to this that I've seen is if you have multiple type that have different class hierachies (like winform controls), you can make a subclass of each that all implement and interface and then extend that interface, thereby giving "base" functionality to a group of different controls, without extending everything like Control or Object. 

Edit: answering your second question

I think the compiler will catch this for you.

blocks|key|3465894|text|你有很多理由不应该这么做。第一个是，你不能保证你的扩展将如何被调用：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3465895|MyExtensions.AMethod(myObj)|code-block|syntax|javascript|3465896|或|3465897|myObj.AMethod()|3465898|第二个仅仅是第一个的句法糖。|3465899|你的建议违背了语言特性的精神。扩展方法肯定不是面向对象的。然而，您正在尝试实现一种面向对象的技术。不要为此使用扩展方法。|3465900|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|R|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|S|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|T|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|U|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|V|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|P|$]]

There's every reason you shouldn't do it. The first of which is, you can't guarantee how your extensions will be called:

<pre><code>MyExtensions.AMethod(myObj)
</code></pre>

or

<pre><code>myObj.AMethod()
</code></pre>

The second is merely syntactic sugar for the first.

What you suggest goes against the spirit of the language feature. Extension methods are decidedly not object-oriented. Yet you are trying to achieve an object-oriented technique. Don't use extension methods for that.

blocks|key|249295|text|这绝对是个坏主意。扩展方法是静态绑定的，这意味着，除非您在编译时类型为子类型的对象上调用重写，否则仍将继续调用扩展方法。再见多态。This+page很好地讨论了扩展方法的危险。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|249296|entityMap|0|LINK|mutability|MUTABLE|url|http://ruben.3click.be/blog/extension-methods-silent-static-slaves^0|1T|9|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

This is definitely a bad idea. Extension methods are bound statically which means that, unless your calling the override on an object whose compile-time type is the sub-type, you'll still continue to call the extension method. Bye-bye polymorphism. <a href="http://ruben.3click.be/blog/extension-methods-silent-static-slaves" rel="noreferrer">This page</a> has a good discussion of the perils of extension methods.

blocks|key|991899|text|这里的所有答案都是“你不能”，就目前而言，这是正确的。大多数人补充说“你不应该这样做”。我想说的是，你应该能够--尽管这可能是一个小小的安慰。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|991900|举一个令人痛苦的现实世界的例子:如果你不幸地使用了新的MVC框架，而你的视图代码到处都在使用某个HtmlHelper扩展方法，并且你想要覆盖它的默认行为……然后呢？|991901|你是索尔，就是这样。即使你做了“面向对象的事情”-从HtmlHelper派生，改变你的基视图类用你的DerivedHtmlHelper的实例替换'Html‘对象实例，并在其中定义一个显式的'Foo’方法-即使你做了所有这些，调用'Html.Foo‘仍然会调用原始的扩展方法，而不是方法。|991902|这太令人惊讶了！毕竟，只有在对象还没有方法的情况下，才需要应用扩展方法！这里发生了什么事？|991903|这是因为扩展方法是一个静态特性。也就是说，当编译器看到'Html.Foo‘时，它会查看'Html’的静态类型。如果它有一个'Foo‘方法，就像往常一样调用它。否则，如果存在提供“Foo”扩展方法的“SomeClass”，则将表达式转换为“SomeClass.Foo(Html)”。|offset|length|style|BOLD|991904|您所期望的是编译器将考虑对象的动态类型。也就是说，生成的(伪)代码应该是'Html.HasMethod("Foo")？Html.Foo()：SomeClass.Foo(Html)‘。|991905|当然，这会导致在每次扩展方法调用中使用反射的开销。因此，您可能希望编写类似“static+void+Foo(virtual+this+HtmlHelper+html)”这样的代码来显式地请求编译器插入运行时检查。将其称为“虚拟扩展方法”。|991906|然而，在有限的预算和无限的智慧中，C#语言设计者只选择了更有效、更受限制的替代方案。这使得我在需要覆盖HtmlHelper的默认行为时仍然是SOL+:-(|991907|entityMap^0|0|0|0|0|B|2|1E|2|0|F|2|0|1I|7|0|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|W|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|X|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|Y|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|Z|8|@$J|10|K|11|L|M]|$J|12|K|13|L|M]]|9|@]|A|$]]|$1|N|3|O|5|6|7|14|8|@$J|15|K|16|L|M]]|9|@]|A|$]]|$1|P|3|Q|5|6|7|17|8|@$J|18|K|19|L|M]]|9|@]|A|$]]|$1|R|3|S|5|6|7|1A|8|@]|9|@]|A|$]]|$1|T|3|-4|5|6|7|1B|8|@]|9|@]|A|$]]]|U|$]]

All answers here stated "you can't", which is true as far as it goes. Most added "and you shouldn't". I would like to make the case that you should be able to - small comfort as this may be.

Take a painful real world example: if you are unfortunate enough to be using the new MVC framework, and your view code is using some HtmlHelper extension method all over the place, and you want to override its default behavior... what then?

You are SOL, that's what. Even if you did the "OOP thing" - derive from HtmlHelper, change your base view class to replace the 'Html' object instance with an instance of your DerivedHtmlHelper, and define an explicit 'Foo' method in it - even if you did all that, calling 'Html.Foo' will still invoke the original extension method and not method.

This is surprising! After all, extension methods are only expected to be applied if the object does not already have a method! What's going on here?

Well, this because extension methods are a static feature. That is, when seeing 'Html.Foo', the compiler looks at the static type of 'Html'. If it has a 'Foo' method, it is called as usual. Otherwise, if there is 'SomeClass' providing a 'Foo' extension method, it converts the expression to 'SomeClass.Foo(Html)'.

What you would expect is that the compiler would consider the dynamic type of the object. That is, that the generated (pseudo-)code would read 'Html.HasMethod("Foo") ? Html.Foo() : SomeClass.Foo(Html)'.

This of course would incur the cost of using reflection in each extension method call. So, you would expect that you could write something like 'static void Foo(virtual this HtmlHelper html)' to explicitly request the compiler to insert the run-time check. Call this a "virtual extension method".

However, in their limited budget and infinite wisdom, the C# language designers went with only the more efficient, more restricted alternative. Which leaves me still SOL when I need to override the default behavior of HtmlHelper :-(

blocks|key|249383|text|首先，检查new作为方法修饰符是很好的-它应该提供相同的性能和方法分离，但麻烦少得多。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|249384|如果在那之后你还在考虑同样的技巧，这里是要考虑的主要选择-不涉及意识形态，只列出你需要知道的部分:-)|249385|首先，您可能必须将所有使用限制为模板化函数参数，以保证确定性函数选择，因为这种技巧将创建与CLR保证跨函数调用边界的确定性绑定优先级完全相反的情况。|249386|如果你仍然拥有抽象基类，并且你拥有所有的代码，那么仅仅将一个基方法“转换”成扩展并不会给你带来任何好处，只会让你失去一个公共接口，而这个接口仍然存在于其他所有东西中，包括vtables的成本。|249387|如果您的目标是将抽象类转换为具体类，出于性能原因消除所有虚方法，并在模板中专门使用具体基类和所有派生类(甚至可能转换为结构)，那么该技巧可以为您带来一些性能。您只需意识到，如果不进行重构，您将无法返回到基于接口的使用。您还需要使用签名中的基类测试非模板函数中的调用顺序，如果有多个‘ll+s，请格外小心。用new操作符尝试同样的方法，看看它是否工作得更好。|249388|此外，您必须为每个派生类编写单独的方法实现，即使它们具有完全相同的功能，因此，如果您有许多派生类，您将看到大量的代码重复。即使您使用new，这一部分也会对您造成冲击，除非您返回到虚拟方法并在继承中引入另一个层-这当然会取消所有性能收益。|249389|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|P|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|Q|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|R|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|S|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|M|$]]

First it would be good to check [new] as a method modifier - it should give the same perf and method separation but with a lot less of a hassle.

If after that you are are still pondering the same tricks, here are the principal options to consider - no ideology involved, just listing apsects you'll need to be aware of :-) 

For a start you may have to limit all uses to templated function params in order to guarantee deterministic function selection since this trick will create the situation which is exact inverse of the one in which CLR guarantees deterministic binding priority across function call boundaries.

If you are still going to have abstract base class and you own all code then just "converting" one base method into extension weill not buy you anything at all and will just cost you the loss of a common interface which will still exist for everything else, including the cost of vtables.

If you are aiming at converting abstract class into a concrete, eliminating all virtual methods for perf reasons and using using concrete base class and all derivatives exclusively in templates (maybe even converting to structs) then that trick could buy you some perf. You just need to be aware that you won't be able to go back to interface-based use without refactoring. You'll also need to test invocation order in non-template functions with the base class in signature and be extra carefull if you have multiple dlls-s. Try the same with [new] operator and see if it works better.

Also, you will have to write separate method implementation for each derived class even if they have exactly the same functionality, so if you have a lot of derived classes you are looking at a lot of code duplication. This part will hit you even if you use [new] unless you go back to virtual methods and introduce another layer in inheritance - which will cancel all perf gains of course.

blocks|key|3466103|text|添加到另一个SO问题的链接，该问题的答案不是“你不能”。更多的是“你不能……除非”。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3466104|How+to+override+an+existing+extension+method|offset|length|3466105|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/1451099/how-to-override-an-existing-extension-method^0|0|0|18|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@$D|P|E|Q|1|R]]|A|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|M]]]]

Adding a link to another SO question that has an alternate answer than the "You can't". More 'you can't....unless'.

<a href="https://stackoverflow.com/questions/1451099/how-to-override-an-existing-extension-method">How to override an existing extension method</a>

blocks|key|249554|text|如果你不需要唯一的派生类，你可以考虑前面提到的多态性。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|249555|此MSDN+article中的一些一般指导原则|offset|length|249556|在类中定义方法后，共享该方法名称的类的任何扩展方法都将不再是executed.|249557|Extension方法，这些方法将按|unordered-list-item|249558|加载。为了允许用户使用其他扩展方法，您可能应该避免将扩展方法放在与被扩展的类相同的命名空间中。|ordered-list-item|249559|249560|249561|如果不同的依赖程序集正在使用同一个库，每个依赖程序集都需要针对库中的一个类使用一个自定义函数，则可以在该程序集中的命名空间中声明特定于依赖程序集的扩展。其他不依赖于该程序集的程序集将不具有该扩展名。|249562|虽然这不是多态性，但您可能不想使用多态性，因为它需要所有派生类实现它们的重写。|249563|换句话说，如果您的派生逻辑具有特定的、可变的逻辑，请使用多态性。如果您只是在特定情况下需要自定义函数，否则可能会令人困惑或繁琐，扩展方法不是一个坏主意。|249564|此外，请参阅JoshRivers的答案，说明如何在单独的命名空间内使用类中的命名空间覆盖扩展方法。|249565|entityMap|0|LINK|mutability|MUTABLE|url|http://msdn.microsoft.com/en-us/library/vstudio/bb383977.aspx^0|0|6|7|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|15|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|16|8|@]|9|@$D|17|E|18|1|19]]|A|$]]|$1|F|3|G|5|6|7|1A|8|@]|9|@]|A|$]]|$1|H|3|I|5|J|7|1B|8|@]|9|@]|A|$]]|$1|K|3|L|5|M|7|1C|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|1D|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|1E|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|1F|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|1G|8|@]|9|@]|A|$]]|$1|T|3|U|5|6|7|1H|8|@]|9|@]|A|$]]|$1|V|3|W|5|6|7|1I|8|@]|9|@]|A|$]]|$1|X|3|-4|5|6|7|1J|8|@]|9|@]|A|$]]]|Y|$Z|$5|10|11|12|A|$13|14]]]]

You may want to consider foregoing polymorphism if you don't need unique derivative classes.

A few general guidelines from this MSDN <a href="http://msdn.microsoft.com/en-us/library/vstudio/bb383977.aspx" rel="nofollow">article</a>:

<ol>
<li>Once a method is defined within a class, any extension method for
that class sharing that method name will no longer be executed.</li>
<li>Extension methods are loaded by namespace. To allow the user of
other extension methods, you should probably avoid putting the
extension methods in the same namespace as the class being extended.</li>
</ol>

If various dependent assemblies are consuming the same library, each requiring a customized function against a class in the library, you could declare the extension specific to the dependent assembly in a namespace within that assembly. Other assemblies which don't depend on that assembly won't have that extension.

While this is not polymorphism, you may not want to use polymorphism as it would require all derived classes to implement their overrides. 

In other words, if you have derivatives with specific, variant logic, use polymorphism.
If you are simply needing custom functions in specific cases that otherwise might be confusing or burdensome, extension methods are not a bad idea.

Also, see JoshRivers' answer showing how to override an extension method using a namespace within a class within a separate namespace.

I've been thinking about using extension methods as a replacement for an abstract base class. The extension methods can provide default functionality, and can be 'overridden' by putting a method of the same signature in a derived class.

Any reason I shouldn't do this?

Also, if I have two extension methods with the same signature, which one is used? Is there a way of establishing priority?

Overriding Extension Methods

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我一直在考虑使用扩展方法来替代抽象基类。扩展方法可以提供默认功能，并且可以通过将具有相同签名的方法放在派生类中来“覆盖”。我有什么理由不这么做吗？另外，如果我有两个具有相同签名的扩展方法，使用哪一个？有没有建立优先级的方法？

问重写扩展方法
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问重写扩展方法EN