Использование частного свойства auto вместо простой переменной для стандартного программирования

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

Таким образом, помимо общедоступного свойства, например:

public int MyProperty1 { get; set; }

Наши частные переменные уровня класса будут выглядеть так:

private int MyProperty2 { get; set; }

Вместо:

private int _myProperty2;

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

Я понимаю, что это дополнительный код для ввода, но, честно говоря, при использовании авто-свойств я не думаю, что когда-либо набирал его из-за фрагментов "prop" и "propg", поэтому было бы очень просто настроить новый фрагмент, чтобы создать частное свойство auto, поэтому дополнительный код меня не слишком беспокоит, так как мне не нужно его вводить.

Помимо эстетики, которая может быть просто моим подсознанием, есть ли какие-либо проблемы, которые могут возникнуть в результате использования полностью частных свойств авто? Есть ли веские причины для этого или нет? Я видел много кода в свой день на stackoverflow, codeplex, codeproject и т.д., И я никогда не видел, чтобы кто-либо использовал этот стандарт... есть ли причина?

Ответ 1

Это не имеет особого смысла.

Я могу придумать "выгоду":

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

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

"есть ли какие-либо проблемы"?

Ваши свойства не будут работать как аргументы параметров ref или out.

Ответ 2

Частные авто-свойства совершенно бессмысленны, на мой взгляд. Какое значение делает частное авто-свойство, равное простому полю?

(Это отличается, когда свойство auto-property является только частично закрытым - например, открытый/защищенный getter с частным сеттером - или когда вы используете частное неавтоматическое свойство, чтобы вы могли обернуть дополнительный код вокруг получателя/сеттера.)

Ответ 3

Это не так полезно для рядовых, как для публики.

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

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

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

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

Ответ 4

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

Ответ 5

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

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

public int MyProperty1 { get; set; }

Кроме того, он уменьшает вашу строку кода и Quick Implementation

Ответ 6

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

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

Сказав это, когда вам нужно преобразовать данные во время их чтения, или когда вам нужно выполнить побочный эффект при обновлении значения, вы должны использовать поле. Меняет ли ваше значение событие? Тогда поле - легкая задача. задавать;}