Здравствуйте, Тепляков Сергей Владимирович, Вы писали:
По поводу:
«Нет, не стоит!», но если данный класс является библиотечным или просто он инстанцируется миллионы раз, то мой ответ уже не будет столь однозначным.
Хоть 10 миллионов раз. Код джитится один раз и держится в одном экземпляре. Совет Рихтера просто идиотский. Экономия на спичках. И то если она есть. Ведь наличие конструктора и его вызов отнюдь не бесплатны. Если он не заклинится, будут инструкции его вызова и возврата. Плюс он раздувает метаданные.
Короче, пример плохой. Хотя поднимаемый вопрос важен.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
ТСВ>Авторы: ТСВ> Тепляков Сергей Владимирович
ТСВ>Аннотация: ТСВ>В статье рассматриваются различные аспекты дизайна приложения и влияние этих аспектов на выбор верного варианта дизайна.
Здравствуйте, Sinatr, Вы писали:
S>Здравствуйте, Тепляков Сергей Владимирович, Вы писали:
S>Почему к примеру с GetEnumerator() не прилагается результат с обьяснением, либо просто ссылка на куда-то где обьяснено? (к примеру, сюда)
Да все просто GetEnumerator() возвращает Enumerator, а это ValueType LOL и при обращении к свойству Enumerator происходит копирование по значению всего элемента, в отличии от ссылочного объекта, когда копирование по значению происзходит только ссылки.
IL_0012: callvirt instance !0 class '<>f__AnonymousType0`1'<valuetype ConsoleApplication1.Program/MyStruct>::get_ValueTypeField()
public struct MyStruct
{
public int Field;
public MyStruct(int field)
{
Field = field;
}
public void Increment()
{
Field++;
}
}
private static MyStruct GetStruct()
{
return new MyStruct(0);
}
Вызов.
var z = new { ValueTypeField = GetStruct() };
for (int i = 0; i < 5; i++)
{
z.ValueTypeField.Increment();
}
Console.WriteLine(z.ValueTypeField.Field);
замена struct на class решает проблему.
Замечу, что обильное использование всяких "фишек" типа иницаилизаторов, анонимных типов и т.д. должно быть оправдано и разработчик должен понимать что происходит "под капотом". Но Enumerator реализованный в List<T> как valuetype хорошая мина
ТСВ>Авторы: ТСВ> Тепляков Сергей Владимирович
ТСВ>Аннотация: ТСВ>В статье рассматриваются различные аспекты дизайна приложения и влияние этих аспектов на выбор верного варианта дизайна.
А в чем цель статьи? Я вот прочитал и что должен для себя вынести?
Здравствуйте, gandjustas, Вы писали: G>А в чем цель статьи? Я вот прочитал и что должен для себя вынести?
В статье это напрямую не говориться, но прежде, чем принимать какое либо техническое решение, надо понять какую проблему решал автор этого решения, какие плюсы/минусы и на сколько это решение подходит в "нашем" случае.
И второе не придумывать себе проблем, если в модели бизнеса вероятность сценария очень мала (из серии за 10 лет это никому не надо было), то не имеет смысла закладывать в этот сценарий какую-либо гибкость — и сделать его максимально быстро и дубово и наоборот уделить внимание наиболее изменчивым областям.
Здравствуйте, diez_p, Вы писали:
_>Здравствуйте, gandjustas, Вы писали: G>>А в чем цель статьи? Я вот прочитал и что должен для себя вынести? _>В статье это напрямую не говориться, но прежде, чем принимать какое либо техническое решение, надо понять какую проблему решал автор этого решения, какие плюсы/минусы и на сколько это решение подходит в "нашем" случае. _>И второе не придумывать себе проблем, если в модели бизнеса вероятность сценария очень мала (из серии за 10 лет это никому не надо было), то не имеет смысла закладывать в этот сценарий какую-либо гибкость — и сделать его максимально быстро и дубово и наоборот уделить внимание наиболее изменчивым областям.