.NET When should I use the function voice / variable + accessor property?

Question

Is there ever a situation where I have to do the following in .NET instead of using a read / write property?

private S as string public function GetS() as string return S end function public sub SetS(byval NewS as string) S = NewS end function 

Do properties really provide a more efficient way to do the same?

Will the property be slower than the above access functions in a high-performance application?

Answer 1

Properties, internal, are nothing more than a couple of methods. They mainly evaluate the get and set accessor methods.

You should use properties if the property does not cause an unexpected, potentially long-lasting side effect, or there are other good reasons to use the method.

For more information, I suggest reading the Guide to Using Properties on MSDN . In particular, use the method when:

• An operation is a transformation, such as Object.ToString.
• The operation is expensive enough that you want to tell the user that they should consider caching the result.
• Retrieving a property value using get accessor will have an observed side effect.
• Calling a member twice in a row gives different results.
• The order of execution is important. Note that type properties must be set and retrieved in any order.
• The element is static, but returns a value that can be changed.
• The element returns an array.

Otherwise, I would use a property. Brad Abram wrote some other details , including good reasons why some API functions use methods (mainly because they can cause inter-computer communication, which falls into the “side effect” category).

Answer 2

Properties are actually syntactic sugar for methods called get_MyProperty and set_MyProperty , so there is no performance difference.

Answer 3

Another decision about whether to use properties or functions is to instantiate the parent object. VB has surprisingly convenient syntax, for example.

 Dim MyStudent as Student With {.Name = "Bobby", .Age = 10} 

In section "C" only properties are available.

I support an application with many stored objects in a database in which there are many relationships between objects. for example, the student has a teacher, and the teacher moved to the database.

I usually use the WriteOnly property to set Teacher, since this is a backlit operation, but if there is a potentially expensive access to the database to retrieve Teacher, I use the retrieve function. In other words:

 Public Writeonly Property Teacher() as Teacher Public Function GetTeacher() as Teacher 

This allows me to create a Student instance in the form With {.Teacher = SomeTeacherObject} , but GetTeacher recommends caching the Teacher object in the user code, and not just use it as a property that may or may not lead to several DB access calls.

If anyone has comments on this approach, I would love to hear them.

Answer 4

Yes, at least in my experience I try to avoid properties and use functions and routines. Here are my reasons:

• You cannot use properties with delegates. I believe you can in C #, but in
• Properties are deceptive; they are similar to members but behave like functions. Therefore, although you might think that you are just looking at the value of a member, you really could initialize the whole system again, because the developer-developer abused the lazy instance.

• Less code, while not a HUGE amount, defining properties in VB requires at least 2 extra lines of code to get or install. The overhead doubles the lines of actual code for one assignment or return operation. Even though this little code makes reading code much more complicated, VB is already obsessively speaking language.

   Private ReadOnly Property Foo As String Get Return Bar End Get End Property 

  vs

   Private Function Foo As String Return Bar End Function 

• The properties are less flexible, you should return the same value that you get. In other words, you cannot set the value with String and get with the Integer parameter or overload with String or Integer .

Now, to be fair, the Reasons I use Properties is to get syntax = for a setting that doesn't apply when you have a read-only property. Also, properties can be set in the VS editor in the properties dialog box.

Answer 5

With N-Tier constructs in my BO, I save property values ​​with an undefined value, and then set it on first access.

 Private _aValue As integer =-1 Private ReadOnly Property aValue As integer Get If _aValue = -1 Then _aValue = DA.General.GetaValue() End If Return _aValue End Get End Property 

This way, I never worry if I parse the properties in the correct order, since I basically lazily load them.