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

Question

Мне нравятся автоматически внедряемые свойства в C #, но в последнее время в моей кабинке стоял слон, и я не знаю, что с ним делать.

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

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

Итак, мой вопрос, что большинство из вас делает? Используете ли вы автоматически внедряемые свойства или предпочитаете всегда использовать вспомогательное поле? Что вы думаете о свойствах с побочными эффектами?

Answer 1

У Эрика Липперта есть отличная запись в блоге , которая отвечает на этот вопрос:

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

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

Answer 2

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

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

Answer 3

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

public string Name 
{
    get; set;
}

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

private string name;

public string Name 
{
    get { return this.name; }
    set 
    {
       if (!string.IsNullOrEmpty(value))
       { 
           this.name = value;
       }
    }
}

Answer 4

Я всегда использую AIP, пока мне не понадобится поле поддержки. Поменять местами не очень сложно:

public string MyString{get;set;}

для

private string myString;
public string MyString{get{return myString;} set{myString = value;}}

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

Answer 5

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