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

Question

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

Так в дополнение к публичной собственности вот так:

public int MyProperty1 { get; set; }

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

private int MyProperty2 { get; set; }

Вместо:

private int _myProperty2;

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

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

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

Answer 1

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

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

Answer 2

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

Я могу подумать о «выгоде»:

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

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

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

Answer 3

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

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

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

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

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

Answer 4

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

Answer 5

Я твердо верю в ПОЦЕЛУЙ. Я никогда не использую свойство, когда поле подойдет, и вижу очень мало причин для использования частных методов доступа (get).

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

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

Answer 6

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

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

public int MyProperty1 { get; set; }

Более того, это сокращает вашу строку кода и Быстрое внедрение