Чи властивості C # насправді є методами?


77

Дотепер у мене склалося враження, що Properties& Methodsце дві різні речі в C #. Але тоді я зробив щось подібне нижче.

введіть тут опис зображення

і це для мене було "Відкривачем очей". Я очікував одного властивості stringPropта одного методу, stringPropале натомість отримав це.

Чому це сталося? може хтось пояснить будь ласка.


4
Не зовсім зрозуміло, що ви шукаєте як відповідь. Але Властивості кажуть: "... насправді це спеціальні методи, які називаються аксесуарами".
Damien_The_Unbeliever


30
Не законно мати властивість і метод з однаковою назвою, тому я не здивований, що Intellisense бентежить.
Mike Zboray

Це не законно, і спроби stringProp = stringProp();не компілювати ( stringProp is a 'property' but is used like a 'method')
Олексій,

Зауважте, що те, що зробило ваші очі "відкритими", - на мій погляд - проблема в інструменті, яка показує двох членів як "перевантаження"; де назви методів не пов’язані між собою. Метод доступу не має однакової назви з властивістю.
Іраванчі

Відповіді:


113

Так, компілятор генерує пару методів get і set для властивості, а також приватне поле резервної копії для автоматично реалізованої властивості.

public int Age {get; set;}

стає еквівалентом:

private int <Age>k__BackingField;

public int get_Age()
{
     return <Age>k__BackingField;
}

public void set_Age(int age)
{
    <Age>k__BackingField = age;
}

Код, який звертається до вашого ресурсу, буде скомпільований для виклику одного з цих двох методів. Це якраз одна з причин, чому зміна публічного поля на державну власність є надзвичайною зміною.

Див. Джон Скіт, чому властивості мають значення .


30
@ dc7a9163d9 Власне, <Age>k__BackingFieldце ім'я поля. Незважаючи на те, що це нелегальна назва в C #, це цілком дійсне ім'я в IL (Intermediate Language). Це IL генерується для оголошення цього поля: .field private int32 '<Age>k__BackingField'. Більшість типів, створених компілятором, таких як лямбда-замикання та перечислювачі, містять <>у своїх іменах.
dcastro

У мене є один метод, який виконує як SET, так і GET. Було б чудово, якби я міг назвати це як власність, без ()
Герман Ван Дер Блом

24

Власне кажучи, властивості не є методами, хоча і є на самому ділі підтримуються методами отримання і установок (також звані аксессор). Коли ви пишете такий код (за умови зміни коду, щоб видалити помилку компіляції, згадану нижче)

myFoo.stringProp = "bar";

Компілятор насправді генерує код IL так:

ldstr       "bar"
callvirt    foo.set_stringProp

Де set_stringProp метод встановлення для цієї властивості. Насправді, якщо ви цього бажаєте, ви можете викликати ці методи безпосередньо за допомогою роздумів.

Однак зразок коду, який ви опублікували, може виглядати нормально в Visual Studio intellisense, але він не компілюється. Спробуйте побудувати проект, і ви побачите таку помилку:

Тип 'foo' вже містить визначення для 'stringProp'


2
Найбільша різниця полягає в тому, що властивості можуть мати додаткові пов'язані метадані через атрибути, які можуть не стосуватися методів.
Ден Брайант,

18

Це питання інтелектуальної візуальної студії, яке вибирає по імені . До речі, ваш код навіть не компілюється через зіткнення імен того самого типу.

Але ви маєте рацію, що властивості - це кінці методів:

public class A {

   public string Name  {get;set;}  
}

тут Nameвластивість перетворюється на 2 методи: get_Name()і set_Name().

Насправді, якщо ви визначите клас так:

public class A {

   public string Name  {get;set;}  

   public string get_Name() {
       return "aaa"; 
   }
}

ви отримаєте помилку компіляції, оскільки вона вже визначена get_Name(властивість)


-2

Так. Властивості - це mutatorметоди.

В інформатиці мутаторний метод - це метод, що використовується для управління змінами змінної. Вони також широко відомі як сеттер-методи. Часто сеттер супроводжується геттером (також відомим як accessor), який повертає значення змінної private member.

Мутаторний метод найчастіше використовується в об'єктно-орієнтованому програмуванні, дотримуючись принципу інкапсуляції. Відповідно до цього принципу, змінні-члени класу робляться приватними, щоб приховувати та захищати їх від іншого коду, і можуть бути змінені лише загальнодоступною функцією-членом (метод мутатора), яка приймає бажане нове значення як параметр, за бажанням перевіряє це, і змінює змінну приватного члена.

Мутаторні методи також можуть бути використані в не об'єктно-орієнтованих середовищах. У цьому випадку посилання на змінну, яку потрібно змінити, передається мутатору разом із новим значенням. У цьому випадку компілятор не може обмежити код в обхід методу мутатора та безпосередню зміну змінної. На розробників покладається обов'язок забезпечити зміну змінної лише за допомогою мутаторного методу, а не безпосередню модифікацію.

У мовах програмування, які їх підтримують, властивості пропонують зручну альтернативу, не відмовляючись від корисності інкапсуляції.

Довідково: http://en.wikipedia.org/wiki/Mutator_method

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.