Допустим, в интерфейсе или базовом классе есть метод, возвращающий фиксированный набор значений, различный для разных реализаций этого метода в разных наследниках. Следует ли считать предпочтительным паттерном заведение в каждом классе своего статик-свойства, значение которого и возвращается при каждом обращении к методу.
Т.е. "естественная" реализация:
"Оптимизированная" реализация:
Или все-таки оптимизатора в данном случае следует считать параноиком, усилия которого .NET съест с большим аппетитом (равно как и GC съест возвращенные экземпляры массивов), и такие оптимизации как мертвому припарки?
Т.е. "естественная" реализация:
* This source code was highlighted with Source Code Highlighter.
enum SomeEnum {...}
class BaseClass()
{
public virtual IEnumerable<SomeEnum> GetValueSet()
{
return new SomeEnum[] { SomeEnum.Value1, SomeEnum.Value2 };
}
}
"Оптимизированная" реализация:
* This source code was highlighted with Source Code Highlighter.
enum SomeEnum {...}
class BaseClass()
{
private static readonly SomeEnum[] valueSet1 = new[] { SomeEnum.Value1, SomeEnum.Value2 };
public virtual IEnumerable<SomeEnum> GetValueSet()
{
return valueSet1;
}
}
class ChildClass() : BaseClass
{
private static readonly SomeEnum[] valueSet2 = new[] { SomeEnum.Value3, SomeEnum.Value4 };
public override IEnumerable<SomeEnum> GetValueSet()
{
return valueSet2;
}
}
Или все-таки оптимизатора в данном случае следует считать параноиком, усилия которого .NET съест с большим аппетитом (равно как и GC съест возвращенные экземпляры массивов), и такие оптимизации как мертвому припарки?
2 комментария:
Если код не вызывается по 1000 раз в секунду, то вообще пофиг. Иначе GC может не успевать освобождать ресурсы. А вообще, лучше профилировать :)
Хотя, он же value type, значит вообще пофиг. Возвращаться-то всё равно будет копия - новая или поля - без разницы.
Отправить комментарий