Изучение автоматически реализованных свойств

Question

У меня есть простой класс, использующий автоматически реализованные свойства:

Public Class foo
{
    public foo() { }  

    public string BarName {get; set;}
}

Я, очевидно, использую переменную BarName во всем классе, и теперь мне нужно добавить логику, когда значение свойства установлено (оно должно быть только в верхнем регистре, см. Рисунок). Означает ли это, что мне нужно создать приватную переменную для BarName, например, _BarName, и измените текущую переменную BarName, используемую в моем классе, на _BarName?

Public Class foo
{
    public foo() {}  

    private string _BarName = "";
    public string BarName 
    { 
        get {return _BarName;}
        set {_BarName = Value.ToString().ToUpper();}
    }
}

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

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

Кажется, это справедливый компромисс между строками и строками кода для настройки свойств.

Answer 1

Значит ли это, что мне нужно сейчас создать приватную переменную для BarName

Да

и изменить текущее BarName переменная используется в моем классе

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

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

Correct.

Answer 2

Вам не нужно ничего менять. Автоматически реализованные свойства являются просто синтаксическим сахаром. Компилятор генерирует приватную переменную и логику get / set для вас, за кулисами. Если вы добавите свою собственную логику получения / установки, компилятор будет использовать ваш код вместо автоматически сгенерированного кода, но с точки зрения users этого свойства ничего не изменилось; любой код, ссылающийся на вашу собственность, будет продолжать работать.

Answer 3

При использовании автоматических свойств вы не получаете прямого доступа к базовой переменной «backing» и не получаете доступа к реальной логике, которая реализуется в свойствах get и set. У вас есть доступ только к свойству (следовательно, вы можете использовать BarName во всем коде).

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

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

Answer 4

Не используйте автоматические свойства, если вы знаете, что собираетесь проверить этот объект. Эти объекты могут быть объектами домена и т. Д. Например, если у вас есть класс Customer, тогда используйте закрытые переменные, потому что вам может потребоваться проверить имя, дату рождения и т. Д. Но если вы используете класс Rss, тогда будет просто использовать автоматические свойства. поскольку проверка не выполняется, а класс просто используется для хранения некоторых данных.

Answer 5

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

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

Answer 6

Вы правы в отношении рефакторинга, и он действительно не должен ничего ломать.

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

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

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

Вам нужно будет просмотреть каждое вхождение доступа к авто-свойству в классе и решить, должно ли оно касаться поля или использовать свойство.