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

Они позволяют пользователю типа иметь упрощенный синтаксис и позволяют создавать поля только для чтения и только для записи. Таким образом me.SetAge (34); age = me.GetAge (); становится me.age = 34; age = me.age;

По крайней мере, для DataBinding
разработка, связанная с пользовательским интерфейсом, без него становится намного сложнее.

Как usr заявляет:

«Свойство имеет коннотацию get без побочных эффектов и того и другого get и set - это быстрая операция "

Точно. Подразумевается, что геттер / сеттер будет быстрым. Раскрывая что-то как свойство, вы подразумеваете, что вы быстро извлекаете / помещаете атрибут в объект. Методы предназначены для выполнения некоторой формы работы, предполагающей большее количество циклов, чем просто получение / установка атрибута. Обычно мы помещаем длительную операцию «свойства» в методы GetFoo (...) / SetFoo (...), чтобы указать, что вычислительная операция тяжелее свойства.

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

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

class Point
{
    private int x, y;

    // Ew, pointless boilerplate!
    public int  getX()      { return x;   }
    public void setX(int x) { this.x = x; }

    public int  getY()      { return y;   }
    public void setY(int y) { this.y = y; }
}

// ...

Point p = new Point();
p.setX(5);
p.setY(10);

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

class Point
{
    public int x, y;
}

Point p = new Point();
p.x = 5;
p.y = 10;

Затем, позже, если вы решите, что хотите добавить какое-то поведение к своим общедоступным переменным, вы можете переключить их на свойства с фактическим поведением в get или set методов. Положительным моментом здесь является то, что это никак не влияет на пользователей вашего класса. Ничего не изменилось; им не нужно переключаться с point.x = 5 на point.setX (5) . поэтому вам придется перекомпилировать весь код, который использует ваш класс, если вы переключаетесь с переменных на свойства. Вы не можете просто перекомпилировать свой класс и отказаться от него вместо старого, если, скажем, ваш класс является частью широко используемой библиотеки. Пользователям вашей библиотеки придется перекомпилировать свой код для новой версии вашей библиотеки.)

Может быть, мелочь, но с геттерами / сеттерами меня раздражает то, что когда я просматриваю их в среде IDE с помощью 'intellisense', возникает огромное количество блок «геттеров» рядом друг с другом и еще один блок «сеттеров». Мне труднее найти то, что ищу.

для меня это просто:

myprop = myvalue;
console.writeline(myprop);

не нужно

mysetfunc(myvalue);
console.writeline(mygetprop);

легче запомнить 1 вещь, чем 2

Помимо семантической правильности использования свойств для значения, описывающего свойство объекта, вы можете Не спорю с этим:

obj.SetValue(obj.GetValue() + 1);

vs

obj.Value++;

Наличие свойств не только в языке, но и в clr означает, что каждый в .NET может полагаться на свои метаданные. Свойство означает получение без побочных эффектов, а получение и установка - это быстрая операция. Многие инструменты используют это предположение: конструктор winforms, LINQ to SQL ...

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

Вот другие типичные предположения:

customer.Name = "a";
Assert.IsTrue(customer.Name == "a");

try { var ignored = customer.Name; }
catch { Assert.Fail("Exceptions are not expected"); }

Два больших преимущества свойств:

• Их можно показать и редактируется в таблице свойств. Не имея свойств, как бы вы узнали, для каких методов показывать редакторы?
• Они предлагают намек на то, что что-то дешевое для чтения и записи и что чтение этого не вызывает побочных эффектов. (Это, конечно, можно нарушить, но, создавая свойство, вы заявляете, что это ваше намерение.) Следовательно, отладчик может уловить этот намек. Если вы наведите указатель мыши на свойство, отладчик покажет его значение во всплывающей подсказке. Было бы бессмысленно делать то же самое для любого возможного метода; слишком легко случайно что-то сделать с побочными эффектами.

Один из популярных способов взглянуть на объектно-ориентированное программирование - моделировать классы в наших программах на основе концепций в нашей голове.

Концепции в наших головах основаны на на реальных объектах, которые мы воспринимаем вокруг нас (независимо от того, воспринимаем ли мы их или общаемся с другими, которые их воспринимали).

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

Вот откуда мы получаем свойства и методы.

В C # свойство не может быть сокращено до одного поля-получения или набора полей (например, это может потребовать дополнительных проверок или может потребоваться кеширование или любое количество причин). Поэтому нам нужна отдельная концепция свойств с помощью методов get и set, чтобы сделать наши программы ближе к концепциям, которые мы хотим, чтобы они моделировали.

Концепции в наших головах основаны на реальных объектах, которые мы воспринимаем вокруг себя (независимо от того, воспринимаем ли мы их или общаемся с другими, которые их воспринимали).

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

Вот откуда мы получаем свойства и методы.

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

Концепции в наших головах основаны на реальных объектах, которые мы воспринимаем вокруг себя (независимо от того, воспринимаем ли мы их или общаемся с другими, которые их воспринимали).

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

Вот откуда мы получаем свойства и методы.

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

Объекты вокруг нас - мебель, животные, космические шаттлы и т. Д. - обладают определенными свойствами и действуют определенным образом.

Вот откуда мы получаем свойства и методы.

В C # свойство не может быть уменьшено к одному field-get или field-set (например, это может потребовать дополнительных проверок, может быть задействовано кеширование или любое количество причин). Поэтому нам нужна отдельная концепция свойств с помощью методов get и set, чтобы сделать наши программы ближе к концепциям, которые мы хотим, чтобы они моделировали.

Объекты вокруг нас - мебель, животные, космические шаттлы и т. Д. - обладают определенными свойствами и действуют определенным образом.

Вот откуда мы получаем свойства и методы.

В C # свойство не может быть уменьшено к одному field-get или field-set (например, это может потребовать дополнительных проверок, может быть задействовано кеширование или любое количество причин). Поэтому нам нужна отдельная концепция свойств с помощью методов get и set, чтобы сделать наши программы ближе к концепциям, которые мы хотим, чтобы они моделировали.

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

Кроме того, если у вас есть общий список объектов, вы можете назначить его DataGridView .DataSource, и вы получите столбец для каждого из ваших свойств. Возможно, это то, что имел в виду @LPalmer.

Свойства по сути - это пары методов получения / установки.

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

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

Я склонен думать, что получить / установить функция более читабельна, чем собственности, поскольку это однозначно функция в отличие от прямого value.

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

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

• Примечание: не все свойства дешевы, но в общих рекомендациях говорится, что они должны быть как можно более простыми и легкими.

Свойства (особенно автоматические свойства в .net 3.5) более лаконичны, чем сеттеры / геттеры, и меньше строк кода == меньше кода для поддержки == меньше ошибок.

Я бы сказал удобочитаемость, но вы уже сказали, что это не будет считаться для вас .. :)