Extension methods and the decline of traditional OOP
-
I didn’t like extension methods back then. I do like them now, provided they aren’t abused.
"Anyone even peripherally involved with computers agrees that object-oriented programming (OOP) is the wave of the future. Maybe one in 50 of them has actually tried to use OOP – which has a lot to do with its popularity."
-
I didn’t like extension methods back then. I do like them now, provided they aren’t abused.
"Anyone even peripherally involved with computers agrees that object-oriented programming (OOP) is the wave of the future. Maybe one in 50 of them has actually tried to use OOP – which has a lot to do with its popularity."
Okay, he's had a change of heart: he likes Extension Methods now ... but ... A very interesting article, imho, for the use of quantitative textual analysis on a large sample of open-sauce flavors. My idea of the right thing to do with any programmer who writes an EM on 'object, 'string, or other fundamental language objects: firing squad. blinded by science, Bill
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
-
Okay, he's had a change of heart: he likes Extension Methods now ... but ... A very interesting article, imho, for the use of quantitative textual analysis on a large sample of open-sauce flavors. My idea of the right thing to do with any programmer who writes an EM on 'object, 'string, or other fundamental language objects: firing squad. blinded by science, Bill
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
I disagree. Extension Methods can be useful on any type which you cannot change, no matter if it's a type in the .Net library or a Third Party component. I wrote extensions on
string
:public static string\[\] SplitTrim(this string \_s, char \_separator) { return \_s.SplitTrim(new\[\] { \_separator }); } public static string\[\] SplitTrim(this string \_s, char\[\] \_separator) { string\[\] split = \_s.Split(\_separator); List collector = new List(); foreach (string item in split) { string trimmed = item.Trim(); if (trimmed.Length > 0) { collector.Add(trimmed); } } return collector.ToArray(); }
Do you see now that they can be useful?
Oh sanctissimi Wilhelmus, Theodorus, et Fredericus!
-
I didn’t like extension methods back then. I do like them now, provided they aren’t abused.
"Anyone even peripherally involved with computers agrees that object-oriented programming (OOP) is the wave of the future. Maybe one in 50 of them has actually tried to use OOP – which has a lot to do with its popularity."
Quote:
decline of traditional OOP
Ehm, that would imply that some when in the past, OOP was in a better state than it is now. The author mentions "Single Responsibility Principle" in his article, which he said was hardly ever observed in his team when Extension Methods were introduced. But let me ask: how many programmers understand the concept of Encapsulation? And that comes before SRP, and SRP is just the first S of SOLID, and ...
Oh sanctissimi Wilhelmus, Theodorus, et Fredericus!
-
I didn’t like extension methods back then. I do like them now, provided they aren’t abused.
"Anyone even peripherally involved with computers agrees that object-oriented programming (OOP) is the wave of the future. Maybe one in 50 of them has actually tried to use OOP – which has a lot to do with its popularity."
The use of extension methods does not negate the use of OOP. Extension methods have their place, and their use should not be discouraged.
".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
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
I disagree. Extension Methods can be useful on any type which you cannot change, no matter if it's a type in the .Net library or a Third Party component. I wrote extensions on
string
:public static string\[\] SplitTrim(this string \_s, char \_separator) { return \_s.SplitTrim(new\[\] { \_separator }); } public static string\[\] SplitTrim(this string \_s, char\[\] \_separator) { string\[\] split = \_s.Split(\_separator); List collector = new List(); foreach (string item in split) { string trimmed = item.Trim(); if (trimmed.Length > 0) { collector.Add(trimmed); } } return collector.ToArray(); }
Do you see now that they can be useful?
Oh sanctissimi Wilhelmus, Theodorus, et Fredericus!
First, I am sure you are among the most experienced, competent, careful programmers; whatever you chose to do, I'd never question. My concern is more that in the context of a complex team project with programmers at different skill/expertise levels that making Extension whoopee with language foundation objects introduces the possibility of broken encapsulation. imho, it's not SOLID. Consider:
public static class StringUtilities
{
public static string[] SplitTrim2(string _s, char _separator)
{
return SplitTrim2(_s, new[] { _separator });
}public static string\[\] SplitTrim2(string \_s, char\[\] \_separator) { return \_s.Split(\_separator, StringSplitOptions.RemoveEmptyEntries) .Select(str => str.Trim()).Where(str => str.Length > 0).ToArray(); }
}
Every programmer using this Class is going to have to reference it per use, or, with a NameSpace 'using statement. In testing and debugging, it is easy, imho, to locate every instance of it's use. In contrast, an Extension Method on 'string ... if in a NameSpace that's accessible by many other project components ... is, imho, an invitation to accidentally use it, possibly create a hard to find dependency. cheers, Bill
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
-
First, I am sure you are among the most experienced, competent, careful programmers; whatever you chose to do, I'd never question. My concern is more that in the context of a complex team project with programmers at different skill/expertise levels that making Extension whoopee with language foundation objects introduces the possibility of broken encapsulation. imho, it's not SOLID. Consider:
public static class StringUtilities
{
public static string[] SplitTrim2(string _s, char _separator)
{
return SplitTrim2(_s, new[] { _separator });
}public static string\[\] SplitTrim2(string \_s, char\[\] \_separator) { return \_s.Split(\_separator, StringSplitOptions.RemoveEmptyEntries) .Select(str => str.Trim()).Where(str => str.Length > 0).ToArray(); }
}
Every programmer using this Class is going to have to reference it per use, or, with a NameSpace 'using statement. In testing and debugging, it is easy, imho, to locate every instance of it's use. In contrast, an Extension Method on 'string ... if in a NameSpace that's accessible by many other project components ... is, imho, an invitation to accidentally use it, possibly create a hard to find dependency. cheers, Bill
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
My use of extension methods has been pretty limited but targeted in scope. Two such extentions are:
public static string RemoveWhitespace(this string value);
// and
public static string ToEnglishProperCase(this string value);I have also used extension methods to perform basic operations that either are not in the .Net Framework or are in there but I haven't found them yet (e.g. adding bytes without casting, getting a sub array of bytes).
if (Object.DividedByZero == true) { Universe.Implode(); }