Adding extension methods, I guess, should be in the framework: a bad idea?
There's one specific feature I needed was in the .NET framework, but it isn't. I would like there to be an overload of DBDataReader.GetString (or GetDateTime, GetInt32, etc.) that took a field name instead of an index. Using the field name makes maintenance easier IMO, but the GetXxx methods only accept the field.
I can add them to my project (at least to a limited extent to suit my immediate needs) using extension methods, but something is not right about that. Apart from the obvious problem that I would have to repeat for every new project, is there any reason not to do what I think about?
For example, am I heading a slippery slope trying to rewrite the structure to suit my moods? I'll leave the poor guy to change my code (maybe me), scratching his head, trying to figure out what's going on? Am I violating some basic OOP principle?
Just look for guidance and perspective. Thank.
source to share
This is definitely one way to extend scripts. You need functionality that is not yet available in a way that you have no control over.
As far as duplicating code in each of your projects is concerned, then you need to create a class library project to hold your shared / shared code like this, and then include that project in each solution and use project references or compile the project, put the resulting assembly in the shared folder and include it as a reference to the project file.
Recall that extension methods are only available if they are "in scope". This means that if you have an extension method defined as:
namespace CustomExtensions
{
public static class StringExtensions
{
public static string InvariantToString(this int value)
{
return value.ToString(System.Globalization.CultureInfo.InvariantCulture);
}
}
}
It will not appear in any string values unless the code file contains the CustomExtensions namespace with the using directive.
For this reason, it is recommended that you do not place your own extensions in a specific .NET Framework namespace, but rather use your own namespace. This minimizes the chances of confusion because your extension will not be available unless it explicitly falls into scope.
Also, keep in mind that if you provide an extension method with the same signature as an inline method, your extension method will never be visible or callable - the inline method always takes precedence. If Microsoft decides to include this functionality in a later version of the Framework and uses the same signature that you chose, your extension method will no longer be called.
When you define an extension method, you are not actually overriding the base type that is being extended, so you don't have "separate versions" of your own. The entire extension method provides a convenient and more natural way to call a static method in a static class. In fact, using the extension method above, these are the equivalent calls:
int i = 42;
Console.WriteLine(i.InvariantToString());
Console.WriteLine(StringExtensions.InvariantToString(i));
While Microsoft does think a lot about what to include or not to include in the Framework, they can't find out about specific use cases that might impact your specific need for certain features. Yes, most of the time they do a great job and provide functionality out of the box, but other times they don't. (The InvariantToString () method is a good example.)
source to share
In fact, I think .NET did it pretty nicely: in order for extension methods to work, you must use the namespace in which they were defined. Visual Studio will show you where the method came from, etc.
Anyway, if you find an abstraction that makes your code easier to read and store, go for it!
source to share
Think about the answers to the following questions, then go and create your extension method. Keeping your job simple is the reason extension methods are part of the language.
- You must wrap extension methods in a namespace specifically for these extensions so that they can be included or excluded at the whim of the developer.
- Placing these extensions in a separate dll will allow you to reuse them without copying files or code between projects.
- Don't forget to think about the design. If others will use it, you want to polish it up a bit and make sure they can use it quickly and easily. It's also a feature that can cause performance issues, so design it in such a way that you can make performance adjustments without changing your extension methods.
source to share
Extensions are syntactic sugar. Basically, everything you do creates some static methods, just like any other static method out there ... with one exception, they save you a little more typing.
However, if you (and your team, if you have any!) Determine that some extension methods will save your user (and your team) time and effort, then add them!
Caveats to this idea:
- Be sure to name your methods so that they don't confuse them with other functionality. (an extension method like: Stream ToStream (this object is o) will certainly be annoying!)
- Make sure you don't add so much that it clutters your intellisense and slows you down! If so, then just leaving them as static methods is probably okay.
- Only add them if you are using this type in your environment. For example, I have a GraphicsPath.Serialize () extensionor for our environment, because I almost always have to serialize my graphics for what we're working on, and I do that a lot. Otherwise, a simple call to my serializer class is sufficient.
- DON'T FORGET that if you have an extension method for your own inner classes, and someone creates a method in that class with the same name, your extension will be outdone!
source to share
Well, in Java, the option is to download and compile your own JRE. Or extend the class through inheritance. Now change your mind, aren't Extentension methods the most effective in your situation?
I would also recommend creating your own "MyNiftyLibrary" to store this code. This is where I store all my "StringHelper", "... Helper" code. Think of it as your personal .NET AddOn.
source to share