кодирования стиля и производительности свойств

Если у меня есть свойство в классе определяется следующим образом:кодирования стиля и производительности свойств

private int mSomeNumber; 
public int SomeNumber 
{ 
    get 
    { 
     return mSomeNumber; 
    } 
}

и внутри одного класса, мне интересно, если люди используют переменный-член, или если вы используете свойство , Например:

public void DoSomething() 
{ 
    if(mSomeNumber == 0) // This way? 
    //if(SomeNumber == 0) // Or this way? 
    { 
     // Do something 
    } 
}

Я думал, что с помощью переменной-члена непосредственно может сохранить вызов, но я задаюсь вопросом, если имущество будет скомпилирован в одно и то же. Кто-нибудь знает, есть ли это или что такое «стандарт»?

источник

2011-01-11 SwDevMan81

Вы должны использовать это свойство, если у вас нет особых требований к обходному пути (пример согласно Henk's answer).

Таким образом, вы можете изменить функциональность в getter без изменения кода вызова. Например, ваш получатель может форматировать значение для более красивого возвращаемого значения, ~~или увеличивать его на константу~~ , или если он просто завершает состояние из другого места (во вложенном объекте) и т. Д.

источник

2011-01-11 22:03:26 Reddog

Я слышал, что увеличение значений в getter's - плохая идея, но я получаю то, что вы получаете, хороший совет. – SwDevMan81

Я предполагаю, что другой пример - это то, что геттер просто завершает состояние из else где (во вложенном объекте). – Reddog

Yuck, отредактируйте этот ответ. Излучатель свойств, который изменяет состояние, является катастрофой в выражении для просмотра отладчика. –

В эти дни, мы просто делаем:

public int SomeNumber 
{ 
    get; 
    private set; 
}

Таким образом, мы не должны беспокоиться объявить частное поле члена.

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

источник

2011-01-11 22:02:07

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

Не всегда. ____ –

Что вы будете делать, если вам нужно реализовать 'INotifyPropertyChanged'? – Femaref

Использование свойств считается лучшей практикой и является стандартной вещью для сетей .net и C# в целом. Это имеет те же преимущества, что и использование свойств вместо полей в публичных контрактах.

Какие преимущества вы получаете, описывает Джон Скит в своей статье: Why Properties Matter.

источник

2011-01-11 22:04:25 Restuta

Разница, если таковая имеется, будет очень маленькой. Поэтому приближение к нему с точки зрения «производительности» неверно. Если вы действительно использовали этого участника, это могло бы иметь значение, вы, вероятно, должны написать его совершенно иначе.

Таким образом, основным критерием является читаемость и надежность. Это означает использование свойства и использование любой (будущей) бизнес-логики.

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

И потому, что это редко, это означает, что мы обычно обойдем без поля поддержки, как в ответе @ Фредерика.

источник

2011-01-11 22:09:31

Это неудивительно, чтобы вызвать любые отличия в производительности, поскольку эти свойства будут почти всегда встроены в JIT.

Существует также абсолютно никакой разницы между декларированием заднего поля как в оригинальном случае, так и с использованием автоматических свойств, как в ответе Фредерика. Оба случая имеют поддержку поля (скрытые в автоматическом случае).

Прочтите другие источники информации о преимуществах свойств.

источник

2011-01-11 23:15:52

кодирования стиля и производительности свойств

ответ

Смежные вопросы