Свойство по сравнению с функцией (конкретно.NET)

Свойства - это не только автоматические свойства. Если вы сделаете:

public int MyProp { public get; public set; }

, тогда он действительно не отличается от

public int MyProp;

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

public int MyProp {
    get {
        // Do some processing
        return someValue;
    }

    set {
        // Do some processing
        DoMyProcess(value);
    }
}

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

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

Например

public class Person {
  private readonly DateTime _birthday;
  public int Age { get { return (DateTime.Now - _birthday).TotalYears; } }
  ...
}

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

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

Показывать переменную из вашего класса считается плохой практикой. Кроме того, если вы измените структуру своего объекта, но сохраните свои свойства без изменений, это не повлияет на код, использующий ваш класс.

Свойства являются удобной заменой операций на основе методов. Функциональной разницы между средством получения значения свойства и методом, выполняющим одни и те же действия, нет; Фактически, если вы посмотрите на IL, вы увидите, что методы доступа к свойствам заменены методами «get» и / или «set».

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

Причина № 1 = Свойства могут использоваться при привязке данных. Методы не могут.

Причина № 2 = При отладке окно наблюдения автоматически открывает свойства / раскрывает объект. Таким образом, методы не отслеживаются автоматически.

Я помню, как где-то читал, что свойство read не должно изменять состояние объекта. Я думаю, что это хорошая практика, особенно учитывая причину №2. Как только вы наблюдаете за объектом и расширяете его, состояние объекта может быть изменено, что затрудняет отладку.

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

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

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