В чем разница между свойством readonly и функцией в .net?

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

    Private m_Property As String 
    Public ReadOnly Property PropertyGet() As String
        Get
            Return m_Property
        End Get
    End Property

    Public Function FunctionGet() As String
        Return m_Property
    End Function

Разборка IL показывает, что нет разницы, кроме имени, но существуют ли различия на другом уровне? Является ли геттер только функцией в короткой (!?) Руке?

Edit: wow, мне очень жаль, что я не могу отметить несколько ответов.

Первый ответ, который указывал на использование свойств для сериализации, - это путь к просветлению, так как я полностью покинул этот аспект. До этого объяснение свойства vs как "is" vs "does" считается произвольным. Теперь я больше его понимаю.

Я думаю, что консенсус в отношении того, что собственность не занимает много времени, проистекает из "is" /serializable концепция. Если моя собственность ведет переговоры с базой данных, чтобы сохранить значение "is" , она ломается ужасно.

ОТВЕТЫ

Ответ 1

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

С другой стороны, функции, процедуры, известные как методы в ООП, являются подпрограммами определения для обработки информации. Должен быть процесс над объектом или частью информации, например, редко встречается имя функции, например DoThis, DoThat... Они могут использоваться по полям или свойствам, но функции известны воздействовать не только на поле, но и контролировать значение над полем. Функции, противостоящие свойствам, могут иметь несколько параметров, необязательные параметры и даже быть дженериками!

Я хотел бы добавить, что, насколько мне известно, свойство не может быть анонимным, но не общим. Внимание, я не говорю, что свойство не может вернуть общий, я говорю, что само свойство не может быть общим. Функция может быть как anonymous, и generic.

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

Ответ 2

Разница более семантическая, чем функциональная; свойство getter на самом деле является функцией под капотом. Разница в том, что в качестве программиста вы часто ожидаете, что вызов объекта getter - очень дешевая операция, а вызов функции потенциально может быть более дорогим.

Обратите внимание, что это не обязательно так; вы можете очень хорошо реализовывать очень легкие функции и очень тяжелые свойства getters, но, как правило, свойство getter обычно не должно ничего больше, чем просто получить значение.

Ответ 3

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

Ответ 4

Вся собственность была, вероятно, задумана, чтобы не получить кучу отдельных методов GetSomething(), SetSomething (var x), которые раньше были нормой, например Java в начале 2000-х для доступа к данным. Это позволит избежать публично открытых переменных.

Поверьте, эти классы выглядели ужасно. Я лично считаю, что концепция собственности - отличный скачок в читабельности и структуре.

Ответ 5

да, свойство - это просто концепция высокого уровня над методами Set/Get.

Ответ 6

Свойство такое же, как функция. Но свойство указывает, что вы получаете (или устанавливаете) "свойства" (переменные-члены) объекта и что эти параметры getter/setter не занимают много времени, то есть f.e. вычисляет что-то или запрашивает базу данных. Поэтому они являются полезным синтаксическим сахаром (если они реализованы правильно).

Ответ 7

Ожидается, что свойства

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

Ответ 8

Свойство get/set является синтаксическим сахаром. Readonly в VB - это просто способ указать, что вы хотите получить функцию "

он может выглядеть так: вы должны передавать свойства по ссылке (ByRef) в методы, но, как вы указываете, это функция, которая не является фактическим типом.

Я обычно использую функции для геттеров, когда операция стоит дорого, например. GetCustomersFromDatabase()

Ответ 9

Я хотел бы добавить, как con для использования свойств, что сериализация понимает концепцию свойств и использует их, пока она ничего не знает о методах getter/setter. Кроме того, если вы используете свойство в компактном стиле, например:

public int MyProperty { get; private set; }

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

Ответ 10

ключевое слово readonly просто означает, что "Дорогой компилятор не ожидает сеттер", и если я это сделаю, наказать меня ". Это решение синтаксиса VB. За кулисами функции и свойства getters одинаковы.

Ответ 11

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

Кроме того, неиндексированные свойства, в отличие от методов, не требуют a() после имени; Я считаю, что индексированные свойства в С# должны использовать [], а не() для их параметров.

Ответ 12

Я только что понял, что вы можете отправлять параметры в свойстве точно так же, как вы делаете это с помощью методов. Это означает, что вы можете написать что-то вроде:

Private _ClientName As String

Public WriteOnly Property ClientName(isValid As Boolean) As String
    Set(value As String)
        If isValid Then
            _ClientName = value
        End If
    End Set
End Property

И тогда вы можете написать это:

ClientName(debt = 0) = "Richard"

Или вот еще одна идея проверить текстовый набор для любого элемента управления меткой:

Public WriteOnly Property OnlyNumbers(label As Label) As String
    Set(value As String)
        If Double.TryParse(value, New Double) Then
            label.Text = value
        End If
    End Set
End Property

Тогда вы можете использовать это так:

OnlyNumbers(lblTotal) = debt

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