Extension Methods - Satan's favourite construct (controversial to nerds)
-
Rob Philpott wrote:
I see no benefit in the piece of code you show above.
It may just be my opinion but I find this
collection.ForEach(item =>
{
//DoStuff
});more readable than
foreach(var item in collection)
{
//DoStuff
}or
foreach(SomeDependentObject item in collection)
{
//DoStuff
}or
for(int i = 0; i < collection.Count(); i++)
{
//DoStuff
}and so on and so forth. It seems more natural when I am coding. I am given the context (the collection) and then I run some action on it for each item.
Rob Philpott wrote:
What happens if an exception is thrown during iteration?
Well then an exception happens as it would with any of the iteration styles above.
Rob Philpott wrote:
You can't tell - depends on what the extension method does.
This is my point. If your extension is complicated and verbose you are doing it wrong. It should be simple and highly intuitive of what it is doing and any exceptions that are being passed in to the extension should not be captured by the extension but show up where the exception actually occurred. This is the nature of
staticclass and has nothing to do with extensions other than that is how you implement extensions.Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.
-
Sometimes I yearn for a return to .NET 2.0. The C# that came with it was a great language and now that generics were included it was essentially complete in my mind. Since then, they've been adding all sorts of dubious things to the language LINQ being the most notable but now we also have the async/await business which really is anything but the simple solution to asynchronous programming they tell us it is. Extensions methods, everyone's favourite encapsulation anti-pattern debuted with LINQ in order to make it work and some people (me) viewed them with suspicious eyes at the time but didn't really know how bad things could get. Having recently worked on a system where they have been abused to the fullest I can tell you. You start off with pretty hollow objects with very little in the way of methods, just enough to get at the data. Then, you put all your logic in extension methods, preferably in different assemblies. A sort of warped onion architecture. Now, any normal developer who goes looking for a type's methods won't find them in the type or even that assembly. A missing reference will make them disappear completely. Also, with careful planning, you can make it exceedingly hard to move that logic back where it belongs because doing so will cause all kinds of circular dependency issues. Immutable code! Shocking stuff, but if you really hate the world, don't forget the Action<> and Func<> delegates. These are useful because you can avoid passing meaningful data to methods. Instead just pass delegates everywhere (a functional programming approach I'm told). This makes it practically impossible for anyone to work out the execution flow by examining the code. Combine the two and you have one thoroughly malevolent system. People bang on about patterns all the time in software development, but if you ask me (I'm aware you didn't) the way to build a good system is to always, always, always keep everything as simple as you can make it.
Regards, Rob Philpott.
-
I am completely opposed to the AS operator. It causes more problems than it is worth. You talk about sloppy programming with extension methods, ugh, AS is worse. In fact, the AS keyword brought down an entire production system. (combined with a lazy programmer) The short story is that instead of relying on strong typing from the DB the developer used AS and converted the type to the expected type. Some DBA decided to change a database type without telling any one and a few weeks later another subsystem broke because of invalid data. Had the type been formally cast this error would have been caught immediately. I am of the camp that strong typing is important. Using conversion ... everywhere as AS encourages, only serves to disassociate developers from types (ok, this includes var) and types and the knowledge thereof is a fundamental underpinning of a stable, large system.
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost "All users always want Excel" --Ennis Lynch
asis excellent in a situation where you don't know what you have, but you might want to do something with it. It saves you the double type check, ofif(x is MyType){
MyType myX = (MyType)x;
myX.whatever;
}instead you have
MyType myX = x as MyType;
if(myX != null){
myX.whatever;
}... which is the same length but more efficient and (imo) more obvious. When you have known types on both sides and known supposed matchups then it is just the wrong tool for the job. It's not the sledgehammer's fault it isn't good at painting windows.
-
Sometimes I yearn for a return to .NET 2.0. The C# that came with it was a great language and now that generics were included it was essentially complete in my mind. Since then, they've been adding all sorts of dubious things to the language LINQ being the most notable but now we also have the async/await business which really is anything but the simple solution to asynchronous programming they tell us it is. Extensions methods, everyone's favourite encapsulation anti-pattern debuted with LINQ in order to make it work and some people (me) viewed them with suspicious eyes at the time but didn't really know how bad things could get. Having recently worked on a system where they have been abused to the fullest I can tell you. You start off with pretty hollow objects with very little in the way of methods, just enough to get at the data. Then, you put all your logic in extension methods, preferably in different assemblies. A sort of warped onion architecture. Now, any normal developer who goes looking for a type's methods won't find them in the type or even that assembly. A missing reference will make them disappear completely. Also, with careful planning, you can make it exceedingly hard to move that logic back where it belongs because doing so will cause all kinds of circular dependency issues. Immutable code! Shocking stuff, but if you really hate the world, don't forget the Action<> and Func<> delegates. These are useful because you can avoid passing meaningful data to methods. Instead just pass delegates everywhere (a functional programming approach I'm told). This makes it practically impossible for anyone to work out the execution flow by examining the code. Combine the two and you have one thoroughly malevolent system. People bang on about patterns all the time in software development, but if you ask me (I'm aware you didn't) the way to build a good system is to always, always, always keep everything as simple as you can make it.
Regards, Rob Philpott.
I dislike them too. Linq is brilliant but it's unfortunate that it requires this mechanism. Extension methods do give you a small amount over an explicit static method, but in my opinion not enough to justify the abuse potential, which unfortunately you have suffered from.
-
Sometimes I yearn for a return to .NET 2.0. The C# that came with it was a great language and now that generics were included it was essentially complete in my mind. Since then, they've been adding all sorts of dubious things to the language LINQ being the most notable but now we also have the async/await business which really is anything but the simple solution to asynchronous programming they tell us it is. Extensions methods, everyone's favourite encapsulation anti-pattern debuted with LINQ in order to make it work and some people (me) viewed them with suspicious eyes at the time but didn't really know how bad things could get. Having recently worked on a system where they have been abused to the fullest I can tell you. You start off with pretty hollow objects with very little in the way of methods, just enough to get at the data. Then, you put all your logic in extension methods, preferably in different assemblies. A sort of warped onion architecture. Now, any normal developer who goes looking for a type's methods won't find them in the type or even that assembly. A missing reference will make them disappear completely. Also, with careful planning, you can make it exceedingly hard to move that logic back where it belongs because doing so will cause all kinds of circular dependency issues. Immutable code! Shocking stuff, but if you really hate the world, don't forget the Action<> and Func<> delegates. These are useful because you can avoid passing meaningful data to methods. Instead just pass delegates everywhere (a functional programming approach I'm told). This makes it practically impossible for anyone to work out the execution flow by examining the code. Combine the two and you have one thoroughly malevolent system. People bang on about patterns all the time in software development, but if you ask me (I'm aware you didn't) the way to build a good system is to always, always, always keep everything as simple as you can make it.
Regards, Rob Philpott.
It's just code. Deal with it.
If your actions inspire others to dream more, learn more, do more and become more, you are a leader.-John Q. Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering.-Wernher von Braun
Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-Albert Einstein -
Sometimes I yearn for a return to .NET 2.0. The C# that came with it was a great language and now that generics were included it was essentially complete in my mind. Since then, they've been adding all sorts of dubious things to the language LINQ being the most notable but now we also have the async/await business which really is anything but the simple solution to asynchronous programming they tell us it is. Extensions methods, everyone's favourite encapsulation anti-pattern debuted with LINQ in order to make it work and some people (me) viewed them with suspicious eyes at the time but didn't really know how bad things could get. Having recently worked on a system where they have been abused to the fullest I can tell you. You start off with pretty hollow objects with very little in the way of methods, just enough to get at the data. Then, you put all your logic in extension methods, preferably in different assemblies. A sort of warped onion architecture. Now, any normal developer who goes looking for a type's methods won't find them in the type or even that assembly. A missing reference will make them disappear completely. Also, with careful planning, you can make it exceedingly hard to move that logic back where it belongs because doing so will cause all kinds of circular dependency issues. Immutable code! Shocking stuff, but if you really hate the world, don't forget the Action<> and Func<> delegates. These are useful because you can avoid passing meaningful data to methods. Instead just pass delegates everywhere (a functional programming approach I'm told). This makes it practically impossible for anyone to work out the execution flow by examining the code. Combine the two and you have one thoroughly malevolent system. People bang on about patterns all the time in software development, but if you ask me (I'm aware you didn't) the way to build a good system is to always, always, always keep everything as simple as you can make it.
Regards, Rob Philpott.
You are touching on a very sore point for me; all these features encourage increasingly bad design. The saying goes "if all you have is a hammer, everything is a nail." Likewise, if what you have is "advanced" .NET 4.x, everything must use the same. Solutions which should be brain dead simple take on a monstrous complexity, especially with the developer who wants everything LINQ"ified". It seems to me that the zeal of getting things done rapidly, including various management methodologies, have trumped long term development and maintenance. My hypothesis is that the latter requires thinking, planning and patience. It more than pays off in the end, but that's not good enough to far too many developers and managers, far too many of them aren't smart enough to do it right anyway. It's simply easier to churn out code that kind of works for now and then quickly move on to another project or company, leaving the train wreck that's going to happen to someone else.
-
Sometimes I yearn for a return to .NET 2.0. The C# that came with it was a great language and now that generics were included it was essentially complete in my mind. Since then, they've been adding all sorts of dubious things to the language LINQ being the most notable but now we also have the async/await business which really is anything but the simple solution to asynchronous programming they tell us it is. Extensions methods, everyone's favourite encapsulation anti-pattern debuted with LINQ in order to make it work and some people (me) viewed them with suspicious eyes at the time but didn't really know how bad things could get. Having recently worked on a system where they have been abused to the fullest I can tell you. You start off with pretty hollow objects with very little in the way of methods, just enough to get at the data. Then, you put all your logic in extension methods, preferably in different assemblies. A sort of warped onion architecture. Now, any normal developer who goes looking for a type's methods won't find them in the type or even that assembly. A missing reference will make them disappear completely. Also, with careful planning, you can make it exceedingly hard to move that logic back where it belongs because doing so will cause all kinds of circular dependency issues. Immutable code! Shocking stuff, but if you really hate the world, don't forget the Action<> and Func<> delegates. These are useful because you can avoid passing meaningful data to methods. Instead just pass delegates everywhere (a functional programming approach I'm told). This makes it practically impossible for anyone to work out the execution flow by examining the code. Combine the two and you have one thoroughly malevolent system. People bang on about patterns all the time in software development, but if you ask me (I'm aware you didn't) the way to build a good system is to always, always, always keep everything as simple as you can make it.
Regards, Rob Philpott.
So, what you are really railing about isn't extension methods, but overly "clever" coders who turn out potentially fragile and over complicated solutions.
I was brought up to respect my elders. I don't respect many people nowadays.
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier -
So, what you are really railing about isn't extension methods, but overly "clever" coders who turn out potentially fragile and over complicated solutions.
I was brought up to respect my elders. I don't respect many people nowadays.
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easierDing ding ding ding ding ding ding!
If your actions inspire others to dream more, learn more, do more and become more, you are a leader.-John Q. Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering.-Wernher von Braun
Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-Albert Einstein -
So, what you are really railing about isn't extension methods, but overly "clever" coders who turn out potentially fragile and over complicated solutions.
I was brought up to respect my elders. I don't respect many people nowadays.
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easierYou could say that, but the thing is the Extension Method is a construct designed to dismantle encapsulation and whilst it may have its place here and there, otherwise it's a dangerous thing. In the wrong hands.
Regards, Rob Philpott.
-
You could say that, but the thing is the Extension Method is a construct designed to dismantle encapsulation and whilst it may have its place here and there, otherwise it's a dangerous thing. In the wrong hands.
Regards, Rob Philpott.
Rob Philpott wrote:
otherwise it's a dangerous thing. In the wrong hands.
You could do dangerous things, even back in 2.0. Ultimately, any tool in the hands of a tool can be misused and abused.
I was brought up to respect my elders. I don't respect many people nowadays.
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier -
Rob Philpott wrote:
otherwise it's a dangerous thing. In the wrong hands.
You could do dangerous things, even back in 2.0. Ultimately, any tool in the hands of a tool can be misused and abused.
I was brought up to respect my elders. I don't respect many people nowadays.
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easierPete O'Hanlon wrote:
Ultimately, any tool in the hands of a tool can be misused and abused.
Great! :laugh:
-
You could say that, but the thing is the Extension Method is a construct designed to dismantle encapsulation and whilst it may have its place here and there, otherwise it's a dangerous thing. In the wrong hands.
Regards, Rob Philpott.
-
You are touching on a very sore point for me; all these features encourage increasingly bad design. The saying goes "if all you have is a hammer, everything is a nail." Likewise, if what you have is "advanced" .NET 4.x, everything must use the same. Solutions which should be brain dead simple take on a monstrous complexity, especially with the developer who wants everything LINQ"ified". It seems to me that the zeal of getting things done rapidly, including various management methodologies, have trumped long term development and maintenance. My hypothesis is that the latter requires thinking, planning and patience. It more than pays off in the end, but that's not good enough to far too many developers and managers, far too many of them aren't smart enough to do it right anyway. It's simply easier to churn out code that kind of works for now and then quickly move on to another project or company, leaving the train wreck that's going to happen to someone else.
Beautifully put, I heartily concur. Often companies seem more interested in their staff understanding 'agile principles' and the very latest trend in development than ensuring people actually understand how to do things. There are a lot of well read agile people out there who really should be in a different profession altogether.
Regards, Rob Philpott.
-
Sometimes I yearn for a return to .NET 2.0. The C# that came with it was a great language and now that generics were included it was essentially complete in my mind. Since then, they've been adding all sorts of dubious things to the language LINQ being the most notable but now we also have the async/await business which really is anything but the simple solution to asynchronous programming they tell us it is. Extensions methods, everyone's favourite encapsulation anti-pattern debuted with LINQ in order to make it work and some people (me) viewed them with suspicious eyes at the time but didn't really know how bad things could get. Having recently worked on a system where they have been abused to the fullest I can tell you. You start off with pretty hollow objects with very little in the way of methods, just enough to get at the data. Then, you put all your logic in extension methods, preferably in different assemblies. A sort of warped onion architecture. Now, any normal developer who goes looking for a type's methods won't find them in the type or even that assembly. A missing reference will make them disappear completely. Also, with careful planning, you can make it exceedingly hard to move that logic back where it belongs because doing so will cause all kinds of circular dependency issues. Immutable code! Shocking stuff, but if you really hate the world, don't forget the Action<> and Func<> delegates. These are useful because you can avoid passing meaningful data to methods. Instead just pass delegates everywhere (a functional programming approach I'm told). This makes it practically impossible for anyone to work out the execution flow by examining the code. Combine the two and you have one thoroughly malevolent system. People bang on about patterns all the time in software development, but if you ask me (I'm aware you didn't) the way to build a good system is to always, always, always keep everything as simple as you can make it.
Regards, Rob Philpott.
I like extension methods. I've added
AddRange()to theObservableCollection, andGetAttribute/GetElementtoXElement, andAddUnique()toList. However, I try not to use anything more complicated than what is needed to make the code work. If I don't need 'em, I don't include my extension classes *unless they're already in an assembly I'm using any way.".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997 -
How does it dismantle encapsulation? You can't do anything with an extension method that you couldn't otherwise do with a static helper method that takes the extended object as a parameter - it's just in a slightly more convenient format.
True, but that static helper would be in a different class and it would be clear to the reader what was going on. Extension methods exist in one type but masquerade as belonging to another, and break encapsulation because their logic is defined outside of the affected type.
Regards, Rob Philpott.
-
Sometimes I yearn for a return to .NET 2.0. The C# that came with it was a great language and now that generics were included it was essentially complete in my mind. Since then, they've been adding all sorts of dubious things to the language LINQ being the most notable but now we also have the async/await business which really is anything but the simple solution to asynchronous programming they tell us it is. Extensions methods, everyone's favourite encapsulation anti-pattern debuted with LINQ in order to make it work and some people (me) viewed them with suspicious eyes at the time but didn't really know how bad things could get. Having recently worked on a system where they have been abused to the fullest I can tell you. You start off with pretty hollow objects with very little in the way of methods, just enough to get at the data. Then, you put all your logic in extension methods, preferably in different assemblies. A sort of warped onion architecture. Now, any normal developer who goes looking for a type's methods won't find them in the type or even that assembly. A missing reference will make them disappear completely. Also, with careful planning, you can make it exceedingly hard to move that logic back where it belongs because doing so will cause all kinds of circular dependency issues. Immutable code! Shocking stuff, but if you really hate the world, don't forget the Action<> and Func<> delegates. These are useful because you can avoid passing meaningful data to methods. Instead just pass delegates everywhere (a functional programming approach I'm told). This makes it practically impossible for anyone to work out the execution flow by examining the code. Combine the two and you have one thoroughly malevolent system. People bang on about patterns all the time in software development, but if you ask me (I'm aware you didn't) the way to build a good system is to always, always, always keep everything as simple as you can make it.
Regards, Rob Philpott.
Couldn't agree more although I don't have anything against LINQ or extension methods I use them sparingly, preferring the simple, easy to understand by someone else in 18 months time approach.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. nils illegitimus carborundum me, me, me
-
You see, without entering into an argument I see no benefit in the piece of code you show above. All you've done is got rid of a couple of lines of clear explicit code which guarantees that people can see what it does and what it does not do. What happens if an exception is thrown during iteration? You can't tell - depends on what the extension method does.
Regards, Rob Philpott.
>>What happens if an exception is thrown during iteration? You can't tell - depends on what the extension method does. Oh please. You can't see that when calling "normal" methods either. So you just put everything in one big god-method so you can see everything directly? You have the same intellisense, the same goto-definition etc on extension methods as on any other method. Abusing extension methods on System.Object etc is bad, but I fail to see how they are bad when used as intended. I've seen developers abuse other features like inheritance etc: public class Order : Address making order inherit address just because orders have a shipping address etc. Bad coders write bad code..
-
Rob Philpott wrote:
otherwise it's a dangerous thing. In the wrong hands.
You could do dangerous things, even back in 2.0. Ultimately, any tool in the hands of a tool can be misused and abused.
I was brought up to respect my elders. I don't respect many people nowadays.
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easierPete O'Hanlon wrote:
Ultimately, any tool in the hands of a tool can be misused and abused.
I think that may imply the following corollary: "any tool that hands a tool to a tool, without knowing the tool receiving the tool knows how to properly use it, is, potentially, abusing, and misusing, themselves, and two other tools." yours, Bill
“Be patient toward all that is unsolved in your heart, and try to love the questions themselves, like locked rooms, and like books that are now written in a very foreign tongue. Do not now seek the answers, which cannot be given you because you would not be able to live them. And the point is, to live everything. Live the questions now. Perhaps you will then gradually, without noticing it, live along some distant day into the answer.”
Rainer Maria Rilke
-
True, but that static helper would be in a different class and it would be clear to the reader what was going on. Extension methods exist in one type but masquerade as belonging to another, and break encapsulation because their logic is defined outside of the affected type.
Regards, Rob Philpott.
Rob Philpott wrote:
break encapsulation
Not any more than a helper method on a helper class does. But, in general, I agree that overuse and misuse of extension methods should be avoided.
If your actions inspire others to dream more, learn more, do more and become more, you are a leader.-John Q. Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering.-Wernher von Braun
Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-Albert Einstein -
But what about CollectionUtils.ForEach(collection, item => { ... })? It's the hiding of the actual location of the code that really gets me about extension methods, and it doesn't gain enough over that snippet to be worth the opacity, imo.
BobJanova wrote:
CollectionUtils.ForEach(collection, item => { ... })
That would not work with the extension that I used as the example.
BobJanova wrote:
It's the hiding of the actual location of the code that really gets me about extension methods
I would agree because I have no idea what you are doing with the collection you are passing in. You should not be using an extension here as it is not intuitive.
BobJanova wrote:
and it doesn't gain enough over that snippet to be worth the opacity
Extensions should not be opaque, but actually clearly state what it is doing. That is my point. If this is not the case then you are doing it wrong.
Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.