Свойства по сравнению с Полями: Нуждаюсь в помощи схватывая использование Свойств по Полям

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

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

Я собирался сказать, что Свойства (сеттеры) - отличное место для создания событий, таких как NotifyPropertyChanged, но кто-то другой меня опередил.

Еще одна веская причина рассмотреть Свойства: допустим, вы используете фабрику для создания некоторого объекта, у которого есть конструктор по умолчанию, и вы подготавливаете объект через его Свойства.

new foo(){Prop1 = "bar", Prop2 = 33, ...};

Но если внешние пользователи обновляют ваш объект, возможно, есть некоторые свойства, которые вы хотите, чтобы они видели как доступные только для чтения и не могли их устанавливать (только фабрика должна иметь возможность устанавливать их)? Вы можете сделать сеттеры внутренними - это, конечно, работает только в том случае, если класс объекта находится в той же сборке, что и фабрика.

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

1) почему я хочу использовать свойства вместо полей (особенно когда это появляется я просто добавляю дополнительные code

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

2) любые советы по распознаванию использования свойства и не рассматривая их как простые методы (за исключением get; set является очевидным), когда отслеживание кода других людей?

Я не совсем уверен, о чем вы спрашиваете, но, отслеживая чужой код, вы всегда должны предполагать, что свойство делает что-то иное, а не просто получает и устанавливает значение. Хотя принято не помещать большие объемы кода в геттеры и сеттеры, вы не можете просто предположить, что, поскольку это свойство, оно будет вести себя быстро.

3) Любые общие практические правила, когда приходит к хорошим методам программирования в отношение к тому, когда что использовать?

Я всегда использую свойства для получения и установки методов, где это возможно. Таким образом, я могу добавить код позже, если мне нужно проверить, что значение находится в определенных границах, а не в нуле и т. Д. Без использования свойств я должен вернуться и поставить эти проверки в каждое место, где я напрямую обращался к полю.

1. Есть несколько причин, по которым вы можете захотеть использовать свойства вместо полей, вот лишь пара:

   a.Имея следующую

    публичную строку MyProperty {get; частный набор; }
   

   вы делаете свойство «только для чтения». Никто, использующий ваш код, не может изменить его значение. Есть случаи, когда это не совсем так (если ваша собственность представляет собой список), но они известны и имеют решения.

   б. Если вы решите, что вам нужно повысить безопасность вашего кода, используйте свойства:

    public string MyProperty
   {
   получить {return _myField; }
   установленный
    {
   если (! строка.IsNullOrEmpty (значение))
    {
    _myField = значение;
    }
    }
   }
   

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

3. Всегда использовать свойства считается хорошей практикой.

Одна из приятных вещей в Properties - это то, что getter и setter могут иметь разные уровни доступа. Рассмотрим следующее:

public class MyClass {

  public string MyString { get; private set; }

  //...other code
}

Это свойство может быть изменено только изнутри, скажем, в конструкторе. Почитайте об инъекции зависимостей. Инъекция конструктора и инъекция свойства имеют дело с установкой свойств из некоторой формы внешней конфигурации. Существует множество фреймворков. Если вы изучите некоторые из них, вы получите хорошее представление о свойствах и их использовании. Инъекция зависимостей также поможет вам в решении третьего вопроса о надлежащей практике.

Когда вы смотрите на код других людей, вы можете определить, является ли что-то методом или свойством, потому что их значки отличаются. Кроме того, в Intellisence первой частью резюме свойства является слово Property.

Хотя мне абсолютно не нравится открывать публично поля напрямую, есть еще одна вещь: поля не могут быть открыты через интерфейсы; Свойства могут.

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

Вы хотите использовать свойства вместо полей, потому что, когда вы используете свойства, вы можете использовать с ними события, поэтому в случае, когда вы хотите выполнить какое-то действие при изменении свойства, вы можете привязать некоторые обработчики событий PropertyChanging или PropertyChanged. В случае полей это невозможно. Поля могут быть общедоступными, частными или защищенными, в случае свойств вы можете сделать их общедоступными только для чтения, но частными для записи.

любые советы по распознаванию использовать свойства и не рассматривать их как простые методы (за исключением очевидного get; set) при трассировке кода других людей?

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

Какие-либо общие практические правила, когда речь идет о хороших методах программирования, в отношении того, когда что использовать?

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

Свойства являются предпочтительным способом покрытия полей для обеспечения инкапсуляции. Однако они функциональны в том смысле, что вы можете раскрыть свойство другого типа и выполнить маршалинг; вы можете изменять модификаторы доступа; они используются в WinForms для связывания данных; они позволяют вам встраивать легкую логику для каждого свойства, например, уведомления об изменениях, и т.д.

При просмотре кода других людей свойства имеют другие значки intellisense, чем методы.

Если вы считаете, что свойства - это просто лишний код, я бы посоветовал придерживаться их в любом случае, но облегчить себе жизнь, автоматически генерируя свойство из поля (правый клик -> Refactor -> Encapsulate Field...)

Свойства позволяют вам делать что-то, кроме установки или получения значения, когда вы их используете. В частности, они позволяют выполнять логику проверки.

Лучшая практика - сделать все, что открыто для публики, Собственностью. Таким образом, если вы позже измените логику установки / получения, вам нужно будет только перекомпилировать свой класс, а не каждый класс, связанный с ним.

Одно предостережение заключается в том, что такие вещи, как «Threading.Interlocked.Increment» могут работать с полями, но не могут работать со свойствами. Если два потока одновременно вызывают Threading.Interlocked.Increment для SomeObject.LongIntegerField, значение будет увеличено на два, даже если другой блокировки нет. Напротив, если два потока одновременно вызывают Threading.Interlocked.Increment для SomeObject.LongIntegerProperty, значение этого свойства может увеличиваться на два, или на единицу, или на -4 294 967 295, или кто знает, какие другие значения (свойство может быть записано использовать блокировку, предотвращающую значения, отличные от одного или двух в этом сценарии, но это не может быть записано для обеспечения правильного приращения на два).