Высокая производительность объектов C #

Я просто хочу знать, какой из следующих подходов рекомендуется с точки зрения производительности и лучших практик. Есть ли разница в производительности?

if (objA.objB.objC.objD.objE != null)
{
   objX.var1 = objA.objB.objC.objD.objE.prop1;
   objX.var2 = objA.objB.objC.objD.objE.prop2;
   objX.var3 = objA.objB.objC.objD.objE.prop3 + objA.objB.objC.objD.objE.prop4;

   ......
   ......
}

or

var objonlyE = objA.objB.objC.objD.objE
if (objonlyE != null)
{
   objX.var1 = objonlyE.prop1;
   objX.var2 =  objonlyE.prop2;
   objX.var3 = objonlyE.prop3 + objonlyE.prop4;
   ......
   ......
}
5
Знаете ли вы, что компилятор найдет прямой путь доступа к свойствам?
добавлено автор Adrian Salazar, источник
там, возможно, разница в производительности, но это незаметно.
добавлено автор mdcuesta, источник
Другая проблема, о которой не упоминалось, заключается в том, что каждая строка будет разрешать значения каждый раз, когда означает, что другой поток изменяет значения (или если свойство getter изменяет их ...), то последующие строки могут давать совершенно разные результаты. Например, если второй поток заменяет objC для другого объекта, тогда разрешение objE несколько раз может фактически привести к другим объектным ссылкам . Ваш второй пример полностью исключает эту возможность.
добавлено автор Chris Sinclair, источник
это плохой дизайн, жаль сказать :(
добавлено автор paritosh, источник

5 ответы

Второй лучше, потому что вы никогда не знаете, что скрывается за «.». Это может быть вызов базы данных или другая дорогостоящая операция.

6
добавлено

Производительность не входит в нее, поскольку доступ к ресурсам будет быстрым (и даже если это не так, это имеет мало значения, если вы получаете доступ к тем же свойствам в том же порядке).

Поддержание и удобочитаемость - это проблемы, и в этом отношении ваш второй вариант намного лучше.

Читайте о Закон Деметры :

Закон Деметры (LoD) или Принцип наименьшего знания - это руководство по разработке программного обеспечения, в частности объектно-ориентированных программ. В его общем виде LoD является конкретным случаем свободной связи.

3
добавлено
Да, но ... Почему бы и не ответить на заданный вопрос: в C# /. NET общие подвыражения не устраняются компилятором, поэтому устранение их вручную всегда приводит к ускорению. Независимо от того, является ли ускорение обнаруженным, это другой вопрос.
добавлено автор Roman Starkov, источник
@romkyns - Точно. Ускорение (?) Здесь не проблема. Я бы лучше указал на вопиющие большие проблемы, которые существуют с первым подходом. И, вы никогда не знаете, не удастся ли будущей версии компилятора исключить подвыражения ...
добавлено автор Oded, источник
@ChrisSinclair - Не сказать, что это будет, просто, что возможно .
добавлено автор Oded, источник
@Oded Я сомневаюсь, что будущая версия сделает это, особенно если это свойства, а не поля. (Лично я бы не хотел, чтобы это произошло)
добавлено автор Chris Sinclair, источник

Во втором подходе у вас меньше места для ошибок программиста, например, в кулаке, вы можете сделать следующую ошибку:

objX.var1 = objA.objB.objC.objD.objE.prop1;
objX.var2 = objA.objB.**objU**.objD.objE.prop2;
0
добавлено

Я предпочитаю второй подход, он гораздо читабельнее. С точки зрения производительности это должно быть незаметно, то есть в случае регулярных переменных/свойств. Если в свойствах есть какие-то тяжелые операции с высокой производительностью, вы также должны использовать вторую версию, поскольку она будет быстрее.

0
добавлено

Второе просто проще в использовании ... Итак, лучше, потому что вы не повторяете свой код снова и снова и снова ...

0
добавлено
Microsoft Stack Jobs
Microsoft Stack Jobs
1 788 участник(ов)

Work & freelance only Microsoft Stack. Feed https://t.me/Microsoftstackjobsfeed Чат про F#: @Fsharp_chat Чат про C#: @CSharpChat Чат про Xamarin: @xamarin_russia Чат общения:@dotnettalks

Software Design and OOP
Software Design and OOP
1 481 участник(ов)

OOP, software design, architecture, GRASP, GoF, SOLID, separation of concerns, безысходность. Пожалуйста, придерживайтесь указанных тем. https://oopru.github.io More cool stuff: @fp_ru @tdd_ru @coding_interview_ru @coding_ru

Microsoft Developer Community Chat
Microsoft Developer Community Chat
584 участник(ов)

Чат для разработчиков и системных администраторов Microsoft Developer Community. __________ Новостной канал: @msdevru __________ Баним за: оскорбления, мат, рекламу, флуд, флейм, спам, NSFW контент, а также большое количество оффтоп тем. @banofbot