snippetcsharpMinor
Is it better to create a class instance, or create an instance each time a method is called?
Viewed 0 times
calledeachcreatemethodbettertimeinstanceclass
Problem
I am creating a converter for use in a Windows 8 XAML app (MVVM). As you can see in the code below, the converter is used to convert a bool into one of two strings from a language resource file.
My question is, is it better to create one instance of
I am specifically concerned about speed and memory use.
My question is, is it better to create one instance of
ResourceLoader for the converter class or should I continue creating new instances each time the method is called?class BooleanToBudgetYearStringConverter : IValueConverter
{
private const string CALENDAR = "BudgetCycle_Calendar",
FISCAL = "BudgetCycle_Fiscal";
private Windows.ApplicationModel.Resources.ResourceLoader loader;
public object Convert(object value, Type targetType, object parameter, string language)
{
string entryName = (value is bool && (bool)value) ? CALENDAR : FISCAL; //The name of the entry desired from the entry file.
return new Windows.ApplicationModel.Resources.ResourceLoader().GetString(entryName);
}
public object ConvertBack(object value, Type targetType, object parameter, string language)
{
return (value is string && (string)value == new Windows.ApplicationModel.Resources.ResourceLoader().GetString(CALENDAR));
}
}I am specifically concerned about speed and memory use.
Solution
Use an Attribute
The class should be tagged with:
If it's of the normal, old-school .NET variety (desktop, client profile, WP8). Windows store apps don't appear to have an analogous attribute in their .NET libraries, and thus this recommendation can be ignored when compiling such a program.
Drop Type Checks
If the passed-in value is not of the expected type, you should not do your conversion; you should allow an exception to be thrown, so that you know an invalid binding has taken place (and you can go correct the offending code). This applies to both conversion and back-conversion.
Explicit Back Conversion
Check for an explicit match -- don't default to returning "false" on a non-match with the CALENDAR string. Instead, check that the input string matches with the FISCAL string. Throw an exception if the input string matches neither acceptable string.
Use a Singleton
The documentation for
The class should be tagged with:
[ValueConversion(typeof(Boolean), typeof(String))]If it's of the normal, old-school .NET variety (desktop, client profile, WP8). Windows store apps don't appear to have an analogous attribute in their .NET libraries, and thus this recommendation can be ignored when compiling such a program.
Drop Type Checks
If the passed-in value is not of the expected type, you should not do your conversion; you should allow an exception to be thrown, so that you know an invalid binding has taken place (and you can go correct the offending code). This applies to both conversion and back-conversion.
Explicit Back Conversion
Check for an explicit match -- don't default to returning "false" on a non-match with the CALENDAR string. Instead, check that the input string matches with the FISCAL string. Throw an exception if the input string matches neither acceptable string.
Use a Singleton
The documentation for
Windows.ApplicationModel.Resources.ResourceLoader implies that the default constructor you're using should result in an object that is identical in function to the one available from the static GetForCurrentView() function. If not, then set up your own singleton pattern to ensure that you have at most one shared copy of the resource object around at any given time.Code Snippets
[ValueConversion(typeof(Boolean), typeof(String))]Context
StackExchange Code Review Q#47938, answer score: 5
Revisions (0)
No revisions yet.