Зачем нужны автосвойства?

Psilon · Регистрация: 10.07.2011

Студворк — интернет-сервис помощи студентам

Вот, возник такой интересный вопрос. Открытое автосвойство

C#
1
public int Property {get;set;}

ничем не отличается от открытого поля

C#
1
public int Field

, но даже мешается: нельзя передавать как ref параметр, другие ограничения имеются. Зачем оно тогда вообще используется?

@kolorotur · 12.07.2012, 18:49

Сообщение от Psilon

Зачем оно тогда вообще используется?

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

Про всякую скукоту типа стандартов и инкапсуляции говорить не буду.

@Lasur · 12.07.2012, 18:56

Основная причина состоит в том, что код, обращающийся к вашему элементу, после компиляции будет выглядеть иначе для свойства, чем для обычного поля. Поэтому, код, обращающийся к полю, приходится рекомпилить, при изменении поля на свойство. Свойство же более гибко, то есть, в дальнейшем вы сможете изменить/добавить необходимые действия в get/set без необходимости рекомпиляции всего кода, использующего ваши элементы.

http://stackoverflow.com/quest... lic-fields
http://blogs.msdn.com/b/abhina... 72694.aspx

Psilon · 12.07.2012, 19:00 **[ТС]**

Jeff Atwood dealt with this a few years ago. The most important point he retrospectively noted is that changing from a field to a property is a breaking change in your code; anything that consumes it must be recompiled to work with the new class interface, so if anything outside of your control is consuming your class you might have problems.

Плохо понял, что имеется ввиду

@Lasur · 12.07.2012, 19:04

Сообщение от Psilon

Плохо понял, что имеется ввиду

Примерно то же, что я написал выше, только упоминается Jeff Atwood, который это "упомянул", видимо, в какой-то статье.

Psilon · 12.07.2012, 19:18 **[ТС]**

Свойство же более гибко, то есть, в дальнейшем вы сможете изменить/добавить необходимые действия в get/set без необходимости рекомпиляции всего кода, использующего ваши элементы.

Можно поподробнее, что значит "без необходимости рекомпиляции"?

@KristopherRobin · 12.07.2012, 19:28

Jeff Atwood dealt with this a few years ago. The most important point he retrospectively noted is that changing from a field to a property is a breaking change in your code; anything that consumes it must be recompiled to work with the new class interface, so if anything outside of your control is consuming your class you might have problems.

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

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

@kolorotur · 12.07.2012, 19:38

Сообщение от KristopherRobin

изменение поля на свойство может серьезно повредить ваш код

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

@KristopherRobin · 12.07.2012, 19:39

поправка - поэтому если что-то что не под вашем контролем работает с вашим классом - у вас могут быть проблемы.

Psilon · 12.07.2012, 19:40 **[ТС]**

Что-то до меня туго доходит

@kolorotur · 12.07.2012, 19:42

Psilon, свойства - это методы GetValue и SetValue.
Разница между ними и открытм полем такая же, как между переменной и функцией.

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

Psilon · 12.07.2012, 19:43 **[ТС]**

kolorotur, смысл писать методы get и set, если она переливают из пустого в порожнее и НЕ осуществляют никаких проверок?

@kolorotur · 12.07.2012, 19:45

Сообщение от Psilon

и НЕ осуществляют никаких проверок?

Ну я вам уже приводил пример с привязкой данных.

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

@Lasur · 12.07.2012, 19:47

Окей, пусть у нас есть сборка со следующим классом:

C#
1
2
3
4
5
6
7
8
9
10
11
12
public class Person
{
    public int Age;
    public string Name { get; set; }
 
    public Person(string name, int age)
    {
        Age = age;
        Name = name;
    }
    //...
}

а некий Василий пишет другую сборку, используя этот класс следующим образом:

C#
1
2
var person = new Person("Jeff", -12);
Console.WriteLine("His name is {0}. He's {1} years old.", person.Name, person.Age);

Потом, вы вдруг решаете сделать некие изменения в вашем классе на проверку валидности вводимых данных:

C#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
public class Person
{
    int _Age;
    public int Age
    {
        get { return _Age; }
        set
        {
            //Я понимаю, что логичнее использовать uint, но... придумайте пример лучше
            if (value < 0) _Age=0;
            _Age = value;
        }
    }
 
    string _Name;
    public string Name
    {
        get { return _Name; }
        set
        {
            if (value.Length > 30) throw new ArgumentException("Name is too long.");
            _Name = value;
        }
    }
 
    public Person(string name, int age)
    {
        Age = age;
        Name = name;
    }
    //...
}

Так вот, код Василия выбросит Runtime Exception при обращении к полю Age, в то время, как обращение к Name пройдет без проблем. И придется Василию заново компилировать свой огромный проект.

А причина вся в том, что свойства компилируется в методы со SpecialName атрибутами, и обращение к ним идет как к методам, а не к полям, несмотря на то, что шарповский сахар "прячет" это от программиста.

@KristopherRobin · 12.07.2012, 19:49

смысл писать методы get и set, если она переливают из пустого в порожнее и НЕ осуществляют никаких проверок?

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

@kolorotur · 12.07.2012, 19:51

Сообщение от Lasur

И придется Василию заново компилировать свой огромный проект.

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

Новые блоги и статьи Все статьи Все блоги /
Новый ноутбук volvo 07.12.2025 Всем привет. По скидке в "черную пятницу" взял себе новый ноутбук Lenovo ThinkBook 16 G7 на Амазоне: Ryzen 5 7533HS 64 Gb DDR5 1Tb NVMe 16" Full HD Display Win11 Pro	Музыка, написанная Искусственным Интеллектом volvo 04.12.2025 Всем привет. Некоторое время назад меня заинтересовало, что уже умеет ИИ в плане написания музыки для песен, и, собственно, исполнения этих самых песен. Стихов у нас много, уже вышли 4 книги, еще 3. . .	От async/await к виртуальным потокам в Python IndentationError 23.11.2025 Армин Ронахер поставил под сомнение async/ await. Создатель Flask заявляет: цветные функции - провал, виртуальные потоки - решение. Не threading-динозавры, а новое поколение лёгких потоков. Откат?. . .	Поиск "дружественных имён" СОМ портов Argus19 22.11.2025 Поиск "дружественных имён" СОМ портов На странице: https:/ / norseev. ru/ 2018/ 01/ 04/ comportlist_windows/ нашёл схожую тему. Там приведён код на С++, который показывает только имена СОМ портов, типа,. . .	Сколько Государство потратило денег на меня, обеспечивая инсулином. Programma_Boinc 20.11.2025 Сколько Государство потратило денег на меня, обеспечивая инсулином. Вот решила сделать интересный приблизительный подсчет, сколько государство потратило на меня денег на покупку инсулинов. . . .
Ломающие изменения в C#.NStar Alpha Etyuhibosecyu 20.11.2025 Уже можно не только тестировать, но и пользоваться C#. NStar - писать оконные приложения, содержащие надписи, кнопки, текстовые поля и даже изображения, например, моя игра "Три в ряд" написана на этом. . .	Мысли в слух kumehtar 18.11.2025 Кстати, совсем недавно имел разговор на тему медитаций с людьми. И обнаружил, что они вообще не понимают что такое медитация и зачем она нужна. Самые базовые вещи. Для них это - когда просто люди. . .	Создание Single Page Application на фреймах krapotkin 16.11.2025 Статья исключительно для начинающих. Подходы оригинальностью не блещут. В век Веб все очень привыкли к дизайну Single-Page-Application . Быстренько разберем подход "на фреймах". Мы делаем одну. . .	Фото: Daniel Greenwood kumehtar 13.11.2025	Расскажи мне о Мире, бродяга kumehtar 12.11.2025 — Расскажи мне о Мире, бродяга, Ты же видел моря и метели. Как сменялись короны и стяги, Как эпохи стрелою летели. - Этот мир — это крылья и горы, Снег и пламя, любовь и тревоги, И бескрайние. . .

@Lasur 267 / 257 / 43 Регистрация: 18.03.2012 Сообщений: 506
	12.07.2012, 18:56
	Основная причина состоит в том, что код, обращающийся к вашему элементу, после компиляции будет выглядеть иначе для свойства, чем для обычного поля. Поэтому, код, обращающийся к полю, приходится рекомпилить, при изменении поля на свойство. Свойство же более гибко, то есть, в дальнейшем вы сможете изменить/добавить необходимые действия в get/set без необходимости рекомпиляции всего кода, использующего ваши элементы. http://stackoverflow.com/quest... lic-fields http://blogs.msdn.com/b/abhina... 72694.aspx 0

@KristopherRobin 145 / 142 / 11 Регистрация: 11.09.2011 Сообщений: 417
	12.07.2012, 19:28
	Jeff Atwood dealt with this a few years ago. The most important point he retrospectively noted is that changing from a field to a property is a breaking change in your code; anything that consumes it must be recompiled to work with the new class interface, so if anything outside of your control is consuming your class you might have problems. Jeff Atwood сталкивался с этим пару лет назад. самое важное что он заметил это то, что изменение поля на свойство может серьезно повредить ваш код. все что работает с этим полем должно быть перекомпилировано, чтобы нормально работать с новым интерфейсом вашего класса. поэтому если что-то вне вашего контрола работает с вашим классом - у вас могут быть проблемы. это про то, что лучше сразу делать свойства, а не поля. чтобы потом не было проблем, если возникет необходимость переделать поле в свойство. 0

@KristopherRobin 145 / 142 / 11 Регистрация: 11.09.2011 Сообщений: 417
	12.07.2012, 19:39
	поправка - поэтому если что-то что не под вашем контролем работает с вашим классом - у вас могут быть проблемы. 0

Psilon Master of Orion 6101 / 4957 / 905 Регистрация: 10.07.2011 Сообщений: 14,522 Записей в блоге: 5
	12.07.2012, 19:40 [ТС]
	Что-то до меня туго доходит 2

@kolorotur 17823 / 12973 / 3382 Регистрация: 17.09.2011 Сообщений: 21,261
	12.07.2012, 19:42
	Psilon, свойства - это методы GetValue и SetValue. Разница между ними и открытм полем такая же, как между переменной и функцией. Думаю, не сложно догадаться что случится, если заменить переменную на функцию и обратно, не обновив участки кода, где они используются. 0

Psilon Master of Orion 6101 / 4957 / 905 Регистрация: 10.07.2011 Сообщений: 14,522 Записей в блоге: 5
	12.07.2012, 19:43 [ТС]
	kolorotur, смысл писать методы get и set, если она переливают из пустого в порожнее и НЕ осуществляют никаких проверок? 0

Зачем нужны автосвойства?

Решение