Зачем когда-либо использовать поля вместо свойств? - PullRequest
36 голосов
/ 30 января 2010

Я довольно новичок в C #, и я думаю, что свойства - замечательная вещь. На самом деле, так замечательно, что я не вижу никакого реального преимущества в использовании полей. Даже для частных полей кажется, что гибкость и модульность, которые предлагают свойства, могут в лучшем случае избавить вас от серьезных головных болей, а в худшем - вообще не дают никакого эффекта.

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

Изменить: Некоторые люди подняли вопрос о необходимости резервного копирования свойств с полями (явно или автоматически). Позвольте уточнить мой вопрос: есть ли причина использовать поля кроме как для резервного копирования свойств ? Т.е., есть ли время, когда SomeType someField; предпочтительнее SomeType SomeProperty { get; set; }?

Edit 2: DanM, Skurmedel и Seth дали действительно полезные ответы. Я принял DanM, поскольку он является наиболее полным, но если бы кто-то суммировал свои ответы в одном ответе, я был бы рад принять его.

Ответы [ 13 ]

2 голосов
/ 30 января 2010

Поля и свойства не являются взаимозаменяемыми. Я предполагаю, что вы говорите о доступе к закрытым полям через частные свойства. Я делаю это, когда это имеет смысл, но по большей части это не нужно. Оптимизатор JIT обеспечит встроенный доступ к частному полю через частную собственность в большинстве случаев в любом случае. И завершение приватного поля в частной собственности не считается серьезным изменением, так как закрытые члены не являются частью вашего интерфейса.

Лично я бы никогда не выставил бы какие-либо защищенные / публичные поля экземпляра. Тем не менее, в общем случае допустимо выставлять открытое статическое поле с модификатором только для чтения, если тип поля сам по себе неизменен. Это часто наблюдается в статических полях SomeStruct.Empty.

0 голосов
/ 12 марта 2015

Есть несколько хороших (частичных) ответов от @Seth (поля работают лучше, поэтому в частном контексте вы также можете использовать это в своих интересах, когда это имеет смысл), @Skurmedel (поля могут быть только для чтения), @Jenk (поля могут быть использованы для ref / out). Но я хотел бы добавить еще один:

Вы можете использовать оптимизированный синтаксис инициализации для установки значения поля, но не свойства. i.e.:

private int x = 7;

против

private int x { get; set; }

// This must go in the constructor, sometimes forcing you to create 
// a constructor that has no other purpose.
x = 7;
0 голосов
/ 30 января 2010

Скорость. Если за время симуляции поле было установлено или прочитано миллиарды раз, вы хотите использовать поле, а не свойство, чтобы избежать издержек или вызовов подпрограммы. В максимально возможной степени в соответствии с OO (DDD?), В этих случаях я бы рекомендовал использовать поля только в классе, предназначенном для представления некоторого вида «значения», подобного человеку. Логика должна быть сведена к минимуму. Скорее, есть личность-создатель или личная служба.

Но если у вас есть эти проблемы, то вы, вероятно, не программируете на c ++ и не на c #, не так ли?

...