Есть ли причина использовать автоматически внедряемые свойства вместо свойств, реализованных вручную?

Question

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

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

    private string _postalCode;

    public string PostalCode
    {
        get { return _postalCode; }
        set { _postalCode = value; }
    }

Вместо:

public string PostalCode { get; set; }

в первую очередь потому, что если я когда-либо захочу выполнить какую-либо пользовательскую реализацию get и set, яЯ должен создать свою собственную собственность в любом случае при поддержке частного поля.Так почему бы просто не откусить пулю с самого начала и сразу придать всем свойствам такую ​​гибкость для согласованности?Это на самом деле не занимает, но лишнюю секунду, учитывая, что все, что вам нужно сделать в Visual Studio, это щелкнуть по имени вашего частного поля и нажать Ctrl + E, и все готово.И если я делаю это вручную, то я получаю несогласованность, в которой есть НЕКОТОРЫЕ открытые свойства, созданные вручную, поддерживаемые приватными полями, и НЕКОТОРЫЕ автоматически реализуемые свойства.Я чувствую себя намного лучше, когда все работает одинаково, либо в автоматическом, либо в ручном режиме.

Это только я?Я что-то пропустил?Я ошибаюсь в чем-то?Я уделяю слишком много внимания последовательности?Я всегда могу найти законные обсуждения возможностей C #, и почти всегда есть плюсы и минусы во всем, но в этом случае я действительно не смог найти никого, кто бы рекомендовал не использовать автоматически реализуемые свойства.

Answer 1

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

Одним из преимуществ использования автоматического реквизита является то, что он потенциально может спасти вас от глупой ошибки кодирования, такой как случайное присвоение неверной частной переменной свойству. Поверь мне, я делал это раньше!

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

Answer 2

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

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

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

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

Answer 3

Одна из вещей, над которыми вы потеряете контроль, - это возможность указать поле поддержки как NonSerialized, но в этом случае достаточно просто создать поле поддержки для свойства.

Забыл: если вы или какой-либо продукт, который вы используете, выполняет отражение над участниками (то есть WCF), тогда вы увидите искаженное имя вспомогательного поля вместо «симпатичного» созданного вами вспомогательного поля.

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

Еще одно уточнение: предположим, что у вас есть веб-сервис, который предоставляет некоторые из ваших бизнес-объектов через WCF созданному вами клиенту silverlight. Чтобы повторно использовать вашу бизнес-логику, ваш клиент Silverlight добавляет ссылки на исходный код для ваших бизнес-объектов. Если у вас есть автоматически реализованные свойства, вы не можете контролировать имя вспомогательного поля. Поскольку WCF сериализует элементы, а не свойства, вы не можете быть уверены, что объект, перенесенный в silverlight из службы WCF, будет десериализован правильно, поскольку имена вспомогательных полей почти наверняка не будут совпадать.

Answer 4

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

Поэтому, когда я использую свойства auto -implemented, Я должен сделать паузу только один раз .

Когда мне нужно поле поддержки Я должен сделать паузу два раза , поэтому это немного замедляет развитие:)

Как я это делаю:

1. Сделать это закрытой переменной в начале
2. Измените его публично автоматически, если необходимо.
3. Измените его на вспомогательное поле, если мне нужен код в get или set.

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

Answer 5

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

Answer 6

Одним из преимуществ, которые я вижу при использовании авто свойств, является;при отладке приложения оно не перейдет в ненужный раздел Get / Set .Я знаю, что мы можем избежать того же самого, используя атрибуты отладчика или Step over;однако это случается в большинстве случаев, если отладка выполняется в большом приложении.