Do extension methods follow the object-oriented paradigm in C#?
Is it a good practice to use extension methods?
In the software development lifecycle how should we consider this question in the design phase?
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 1
Eric Lippert has blogged about this and I suspect I can’t do much better than to quote him:
So, yes, the oft-heard criticism that
“extension methods are not
object-oriented” is entirely correct,
but also rather irrelevant. Extension
methods certainly are not
object-oriented. They put the code
that manipulates the data far away
from the code that declares the data,
they cannot break encapsulation and
talk to the private state of the
objects they appear to be methods on,
they do not play well with
inheritance, and so on. They’re
procedural programming in a convenient
object-oriented dress.They’re also incredibly convenient and
make LINQ possible, which is why we
added them. The fact that they do not
conform to some philosophical ideal of
what makes an object-oriented language
was not really much of a factor in
that decision.
I would add, however, that they’re useful beyond just LINQ – for the same reason that they’re useful in LINQ. It’s really nice to be able to express algorithms which work on arbitrary implementations of a particular interface (such as IEnumerable<T> in LINQ to Obhects). Such algorithms typically don’t have any context beyond the interfaces you’re working on, so they’re often naturally static.
If you accept that you’ve got some static utility method, which syntax would you rather use?
// Traditional CollectionUtils.Sort(collection); // Extension methods collection.Sort();
The latter is simply more readable in my opinion. It concisely expresses what you want to do. It doesn’t make it clear how you want to do it, but that’s less important for most of the time – and more important when you’re debugging that particular line, of course.
Method 2
Extension methods are not an object oriented language feature. (compared to: classes, inheritance, polymorphism etc).
Like every language feature, it should be used where it is appropriate and for what it is designed for. There are already dozens of questions about when and how to use Extension methods.
- What are the best practices for using Extension Methods in .Net?
- Possible overuses of Extension Methods
- Do Extension Methods Hide Dependencies?
Method 3
There are two parts to it.
-
Is it OO when we use it
No; it makes you feel that you are calling method on the particular type - Is it OO based on how it is compiled/built
Yes; Compiled code has a static method using the object on which extension method was invoked
Method 4
Extension methods are just a language feature. They work on object instances and are very nice tool.
Consider them as a different way to extend class functionality. You can add new functionality to a class:
- By adding a partial class declaration. The class then instantly gets a bunch of new methods and properties.
- By including a namespace with your extension methods holder class. The class then gets a bunch of new methods again.
Rather an organizational / language feature. Does not break object-oriented concept in any way. Just as header/source file division in C/C++ has nothing to do with object-orientation, just a language/framework feature.
Method 5
It depends. Extension methods are just a tool. They can be very useful when used appropriately. But if you use them too much, it can obscure your code.
Method 6
Extension Methods are just static methods that work with a specific Class or Class Hierarchy. Python is OO but has modules, Ruby has mixins. I see it more as a language feature. I am pretty sure its still OO friendly
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0