.net 中的 readonly 属性和函数有什么区别？

Question

Apart from an architectural point of view, i'm wondering if there is any difference in .net between a readonly property and a function. Are properties only conceptual wrappers around functions?

    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

Disassembling IL shows that there's no difference apart from the name, but are there differences at another level? Is the getter just a function in short(!?)hand?

---

Edit : wow, i'm really sorry about not being able to mark multiple answers.

The first answer that pointed out the use of properties to serialize was the road to enlightenment since i had completely left this aspect out. Before that, the explanation of property vs function as "is" vs "does" felt arbitrary. Now, i grok it more.

I think the consensus on property being not time consuming stems from the "is"/serializable concept. If my property talks to a database to store the "is" value, it breaks in horrible ways.

Answer 1

The difference is more semantic that functional; a property getter is in fact a function under the hood. The difference is more that as a programmer, you often expect that calling a property getter is a very cheap operation, while calling a function could potentially be more expensive.

Note that this is not necessarily the case; you can very well implement very light-weight functions, and very heavy property getters, but as a rule of thumb, a property getter should typically do nothing much more than simply get the value.

Answer 2

如果您使用数据绑定，则有一个重要区别，您根本无法绑定到方法，只能绑定到属性。

Answer 3

The whole property thing was - probably - conceived to avoid getting a bunch of separate GetSomething(), SetSomething(var x) methods, which used to be the norm in, for example, Java in the early 2000s for data access. This to avoid publicly exposed variables.

Believe me, those classes looked awful. I personally think the property concept is a great leap forward in readability and structure.

Answer 4

A property combines both concepts of fields and methods. In fact, a property is accesed like a field, but the underlying pieces of code are methods. The field part of a property allows you to access a value just like a field would do, though allowing you to trick this getter function and setter procedure, if I may say. Properties are most commonly used to control over a field value that is assigned or returned. And under the risk to repeat myself, they are accessed as a field.

On the other side, functions, procedures, both known as methods in OOP, are by definition routines to process the information. There need to be a process over an object or piece of information, for example, it is not rare to encounter a function's name like DoThis , DoThat ... They can be used over fields or properties, but functions are known to impact more than just a field, or control a value over a field. Functions, by opposition to properties, can have multiple parameters, optional parameters, and even be generics!

I would like to add that, to my knowledge, a property cannot be anonymous, neither generic. Attention, I do not say that a property cannot return a generic, I say that the property itself cannot be generic. A function can be both anonymous , and generic .

In short, a property is a concept used over a field, to gain control over a field value, while functions are doers, we expect them to perform tasks, and not just assignments.

Answer 5

是的，属性只是 Set/Get 方法的高级概念。

Answer 6

A property is the same as a function. But a property indicates that you are getting (or setting) "properties"(Member Variables) of an object and that these getter/setter are not time consuming function that fe calculates something or queries the database. Therefor they are a useful syntactical sugar (if they're implemented correctly).

Answer 7

get properties are expected to be pure, and if you look into the .net Code Contracts, you'll see they assume getters are pure. Thus, calling a property get once, twice or 10 times shouldnt have any difference to the object, where as calling a method on an object, may lead to multiple changes to the objects state.

Answer 8

Property get/set is syntatcit sugar. Readonly in VB is just a way of specifying that you only want the get 'function'

it can then look like you should pass properties by reference (ByRef) to methods but as you point out it is a function not an actual type.

I do tend to use functions for getters when the operation is expensive, eg GetCustomersFromDatabase()

Answer 9

I'd like to add, as a con for using properties, that serialization understands the concept of properties and uses them while it does not know anything about getter/setter methods. Plus, if you are using a property in a compact style like:

public int MyProperty { get; private set; }

you can spare quite a lot of lines of code from your source files, making them more readable.

Answer 10

the keyword readonly just means "Dear compiler don't expect a setter" "and if i do so, punish me". This is a decision of VB syntax. Behind the scenes functions and property getters are the same.

Answer 11

The normal debug watch window for a class will show the values of non-indexed properties, but will not show the results of functions. One of my pet peeves with the StringBuilder class is that it does not have a property for the current string content, which makes the watch window much less useful than it would otherwise be.

Also, non-indexed properties, unlike methods, do not require a () after the name; I believe indexed properties in C# are required to use [] rather than () for their parameters.

Answer 12

I just realized that you can send parameters in a property exact same way you do it with methods. This implies you can write something like:

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

And then you can write this:

ClientName(debt = 0) = "Richard"

Or here is another idea to validate the text set to any label control:

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

Then you can use it like this:

OnlyNumbers(lblTotal) = debt

What I am not sure is if this is considered a "good practice" or at least a "correct" use of a property.