В чем разница между get/set и обычной переменной?

Question

[Артем]

Часто вижу в коде подобное:

public int trade_id { get; set; }
public string type { get; set; }
public string quantity { get; set; }
public string price { get; set; }
public string amount { get; set; }
public int date { get; set; }

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

Comments

[Alexander]

1. Наглядно.
2. В VS, когда указаны get-set то в коде над переменными отображается количество ссылок на переменную.

[GavriKos]

Alexander,

2. В VS, когда указаны get-set то в коде над переменными отображается количество ссылок на переменную.

с обычной переменной то же самое

[Alexander]

GavriKos, возможно это где-то включается/выключается, но по умолчанию нет:

Answer 1

[Станислав Макаров]

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

Правда осознанно это делают только авторы библиотек/nuget-пакетов (публичных или приватных, в рамках компании), остальные скорее потому, что так сказали.

Answer 2

[V Sh.]

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

Comments

[freeExec]

У вас цитата склеилась.

[Alexander]

freeExec, ничего там не склеиловь. Все сообщение - цитата. Отсюда

Answer 3

[Hemul GM]

Что будет, если всё же в будущем решишь добавить проверку? А я скажу, что будет, будешь переписывать код везде, где используешь эту переменную) А умные люди добавят setter или getter метод и всё сразу будет работать.

Comments

[V Sh.]

С современными IDE - это не проблема.
Да и без них - тоже. Просто нужно будет сделать локальную переменную и сеттер/геттер с именем переписываемой переменной.

[Hemul GM]

V Sh., тем не менее, это потенциальный источник багов

[Артем]

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

[Hemul GM]

Артем, не настолько, чтобы ими пренебрегать

[Роман]

Артем, не прав, да геттер и сеттер это фактически функции, на , но если посмотреть код, который генерирует jit, то такие автосвойства заменяются на прямое обращение к памяти, jit оптимизирует сильно такие вещи (естественно в release сборке)
1. Свойство инкапсулирует всю логику работы с собой, которая содержится в одном месте, (смотрим SOLID принципы), а не разбросана по всей программе.
2. свойство можно сделать только для чтения!!!, поле нет. можно сделать сеттер приватным.
3. В WPF привязка возможна только к свойствам.

это навскидку, можно конечно еще найти разницу.

[Василий Банников]

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

Справедливости ради, на уровне синтаксиса разницы в обращении к свойству и полю нет.
А в пределах одной сборки всё равно всё придётся перекомпилировать.

Answer 4

[Василий Банников]

Если опустить философские размышления об инкапсуляции и о расширении, то остаётся не так уж и много.

Многие библиотеки, например всякие сериализаторы, работают только со свойствами, но не с полями.
Если работаешь с EF - тоже нужно всё через проперти делать.

В целом, никаких проблем при использовании свойств, кроме дополнительных 9 символов нет.