Вопрос по oop, .net – Почему мы используем свойства .NET вместо простых старых функций get / set?

17

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

public int NormalClass::getQuality() {
    return this->quality;
}

а также

protected void NormalClass::setQuality(int q) {
    this->quality = q;
}

?

Какие дополнительные преимущества предлагает свойства .NET, помимо эстетики?

Я приму «удобочитаемость» если вы можете привести убедительные аргументы в пользу этого; но лично я склонен считать, что функция get / set более читаема, чем свойство, поскольку она однозначноfunction в отличие от прямой стоимости.

EDIT: Спасибо всем за ответы! Это было действительно информативно для меня; Подводя итог тому, что я собрал / узнал из всего сказанного, ниже приведены несколько выводов, к которым я пришел к настоящему времени:

The greatest benefits of properties come not from specific features of properties themselves, but rather from framework and IDE features which handle properties in a special way; e.g., the Properties editor, XML serialization, data binding. Properties can be treated as simple values in certain convenient ways that get/set functions can't: in particular, obj.Prop++ and obj.Prop = value. Properties let you get away with quick and dirty code using public members without going through the headache of implementing a bunch of get/set functions later; if you should ever need to add some logic and/or make a public member private, you can simply introduce a property and not risk breaking any old code.

Теперь есть один момент, который был сделан в 2 или 3 ответах до сих пор, что я лично нахожу несколько сомнительным: эти свойства подразумевают недорогие операции чтения / записи и поэтому могут использоваться по существу так же, как простые переменные. Моя проблема с этим моментом заключается в том, что нет ничего, присущего свойствам, которые фактически обеспечивают это; это просто, как ониsupposed использоваться. На мой взгляд, это похоже на «shouldBePrivate» квалификатор, который указывает значениеshould быть доступным непосредственно только его собственным классом, но к которому все равно можно получить доступ извне; или полиция, которая патрулирует улицы, чтобы напомнить нам, что мыshould вести себя, но на самом деле не вмешивается, когда мы начинаем совершать преступления (если оно не применяется, что это на самом деле делает для нас?).

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

& quot; если свойства имеют какой-то встроенный механизм для обеспечения дешевизны чтения / записи & quot; - Это как сказать, что было бы лучше, если бы [ваша любимая структура графического интерфейса пользователя] имела какой-то встроенный механизм, гарантирующий, что люди не пишут плохие пользовательские интерфейсы ». Увы, единственный механизм для этого называется «программист». (Или дизайнер, или юзабилити, или что-то в этом роде.) Вам может помочь компилятор, но вы должны взять на себя некоторую ответственность за то, чтобы не писать плохой код. Joe White
... только потому, что ты можешь, хе-хе victor hugo
Джо, я думаю, что это, по сути, моя точка зрения: использование свойств само по себе МОЖЕТ гарантировать недорогие операции чтения / записи. Это ответственность программиста. Я не спорю, что для фреймворка было бы неплохо иметь стандартный, одобренный подход для реализации свойств быстрого доступа; скорее, я подвергаю сомнению те ответы, которые указывают на эту де-факто особенность свойств как функциональное преимущество, как если бы это была какая-то особая особенность, которую разработчики .NET усердно трудились, чтобы обеспечить. Dan Tao

Ваш Ответ

15   ответов
2

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

10

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

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

Error: User Rate Limit Exceeded Dan Tao
2

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);

о свойствами вы можетеeliminate the boilerplate геттеры и сеттеры для 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), Вашpublic interface is stable, что позволяет вам сначала использовать простые переменные и переключаться на более медленныеget/set методы позже, когда вы добавляете некоторые охрану / ведение журнала / что угодно.

class Point
{
    public int x { get; set; }
}

// No change! 
Point p = new Point();
p.x = 5;
p.y = 10;

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

Error: User Rate Limit Exceeded Dan Tao
0

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

3

которое описываетproperty объекта, вы не можете спорить с этим:

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

против

obj.Value++;
2

для меня это легко:

myprop = myvalue;
console.writeline(myprop);

нет необходимости

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

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

Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded
4

They can be shown and edited in the Property Grid. Without properties, how would you know which methods to show editors for? They offer a hint that something is cheap to read and write, and that reading it causes no side effects. (It's possible to violate that, of course, but by making something a property, you're declaring that that's your intent.) Therefore, the debugger can take that hint. If you hover the mouse over a property, the debugger will show its value in a tooltip. It wouldn't make sense to do the same thing for any possible method; too easy to accidentally do something with side effects.
Error: User Rate Limit Exceeded Dan Tao
Error: User Rate Limit Exceeded
4

граммирование является моделирование классов в наших программах на основе концепций в наших головах.

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

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

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

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

Error: User Rate Limit Exceeded Dan Tao
Error: User Rate Limit Exceeded
3

are получить / установить метод пар.

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

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

I'm inclined to think a get/set function is more readable than a property since it is unambiguously a function as opposed to a straight-up value.

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

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

Note: not all properties are cheap, but the general guidelines state that they should be as simple and lightweight as possible.
1

USR состояния:

"A property has a connotation of get being without side effects and both get and set being a fast operation."

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

0

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

13

чем сеттеры / получатели, и меньше строк кода == меньше кода для поддержки == меньше ошибок.

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

Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded Dan Tao
Error: User Rate Limit Exceeded
7

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

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

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

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

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

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

24

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

Что касается того, почему использовать свойства вместо методов получения / установки, я бы предложил следующие мысли:

Properties provide a cleaner, more concise syntax that is easy to understand and read. Properties enable assignment expression chaining: A.x = B.y = C.z Properties convey the semantics of data access clearly and consistently - consumers expect that there are no side effects. Properties are recognized by many libraries in .NET for tasks such as XML serialization, WPF bindings, ASP.NET 2-way binding, and more. Properties are recognized by the IDE and many visual designers and can be displayed in a property editor. Properties enable support for the increment (++) and decrement (--) operators. Properties can be easily differentiated from methods using reflection and allow dynamic consumers to extract knowledge about the data exposed by an object. C# 3 supports automatic properties which helps eliminate boilerplate code.
Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded Dan Tao
Error: User Rate Limit Exceeded

Похожие вопросы