Extension method is a really helpful feature that you can add a lot of functions you want in any class. But I am wondering if there is any disadvantage that might bring troubles to me. Any comments or suggestions?
相关问题
- Sorting 3 numbers without branching [closed]
- Graphics.DrawImage() - Throws out of memory except
- Why am I getting UnauthorizedAccessException on th
- 求获取指定qq 资料的方法
- How to know full paths to DLL's from .csproj f
The null-checking with static methods is different. Not necessarily better or worse - but different, and the developer needs to understand that. Being able to call a method on a null value can be unexpected, and can (at times) be very useful.
No polymorphism (although overloading is supported)
You can get into a mess with ambiguity if two extension methods conflict for the source type (and neither qualifies as "better"). The compiler then refuses to use either... which means adding an extension method in assembly A can break* unrelated code in assembly B. I've seen this a couple of times...
You can't use in with C# 2.0, so if you are writing a library for C# 2.0 it doesn't help
It needs [ExtensionAttribute] - so if you are writing a library for .NET 2.0 you get into a pickle: if you declare your own [ExtensionAttribute], it might conflict from a .NET 3.5 caller
Don't get me wrong though - I'm a big fan!
You can probably guess I'm currently writing a library that needs to work for C# 2.0 and .NET 2.0 callers - and where (annoyingly) extension methods would be really, really useful!
*=for the compiler only; code that is already compiled will be fine
Couple of things:
Extension methods are fun, but there are potential problems with them. For instance, what if you write an extension method and another library creates an extension method with the same signature? You will end up with difficulties in using both namespaces.
Also, it can be argued that they are less discoverable. I think it depends on this one. In some cases your code should be wrapped up in a class, in other cases it's fine to add that functionality as an extension method.
I generally make extension methods as wrappers to my own classes or BCL classes, and put them in a different name space. e.g. Utils and Utils.Extensions. That way the extesions don't have to be used.
Its hard for me to imagine to add a method without knowing intimately about an existing code. For example, you've been using a third-party class to do something, what would be the need for you to extend functionality of this class given that you're not the original developer and you have no ideas how things are structured in the class? It's almost pointless to do such a thing just like it's pointless to drive when you can't see. In the case LINQ where it's implemented by Microsoft designers/codes, it made a lot of sense since they possess the knowledge of how say an internal of implementation of a sequence and now they want to extend its functionality by adding the Count method to count all the elements in the sequence. By having said this, I wish someone would argue me wrong by giving a realistic example where extension method is needed.
As far as disadvantages go, I would see them a bit like macros - you can potentially end up with code that is harder to maintain because others might not be familiar with the extensions you added.