0

In a VB.NET I noticed that I'm able to create a property directly by using the Property keyword followed by the property name and the datatype without the need for the getter and setter method while I can't do this in C#!

Nevertheless, this property seems to be encapsulated as if I were put it in a getter and setter method!

Please take a look at the below screenshot.

enter image description here

In the screenshot above, the property I'm talking about is the number1, and I've created another property encapsulated in a getter and setter method called number2.

Then, I've created a new instance of the Class1 in the Class2, but I've noticed that the number1 property isn't exposed until I've created an instance of its class which is the same as if it was encapsulated in a getter and setter method like the number2 property!

Any explanations?

  • It even creates a hidden variable with the prefix _ – the_lotus Aug 23 '18 at 15:05
  • 1
    _”I've noticed that the number1 property isn't exposed until I've created an instance of its class”_ - Could you please elaborate what you mean by this? No member (property, field, method, or otherwise) are exposed before you create an instance of their parent class _unless_ you mark them as [**`Shared`**](https://learn.microsoft.com/en-us/dotnet/visual-basic/language-reference/modifiers/shared). – Visual Vincent Aug 23 '18 at 15:05
  • Thanks for the clarification, I used to think that the role of the Getter & Setter is to hide a class fields from being exposed to the rest of the application before creating an instance of its class. – Haytham Amairah Aug 23 '18 at 16:16

2 Answers2

6

This is called an "auto property", and is pretty clearly defined in the VB.NET documentation:

Public Property Name As String
Public Property Owner As String = "DefaultName"
Public Property Items As New List(Of String) From {"M", "T", "W"}
Public Property ID As New Guid()

Are all auto-properties with both a getter and setter (and an automatically created backing-field).

C# requires you to use the {get; set;} but is basically the same (because C# doesn't have the Property keyword, it needs something to differentiate it between a field and a property, so the {get; set;} does that). C# is a little different though in that you can define getter-only properties without the {get; set;}...

public int MyProperty => 10;

Would be equivalent to

public int MyProperty { get { return 10; } }
Ron Beyer
  • 11,003
  • 1
  • 19
  • 37
  • 1
    Does VB.Net have the equivalent of C#'s `public int Number => number` ([Read-only expression body properties](https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/statements-expressions-operators/expression-bodied-members#property-get-statements))? – Ivan García Topete Aug 23 '18 at 15:03
  • @IvanGarcíaTopete Not that I know of or that I can find. – Ron Beyer Aug 23 '18 at 15:05
  • 1
    There's still no such [expression-bodied members in VB.NET](https://stackoverflow.com/questions/37790483/expression-bodied-members-for-vb-net). Also newer version of C# allows expression-bodied members in both getter & setter. – Tetsuya Yamamoto Aug 23 '18 at 15:31
  • Thank you Ron, you know what I want! The article you mentioned is really what I'm looking for. – Haytham Amairah Aug 23 '18 at 16:49
  • @RonBeyer, do you know how to access the backing-field within the class in C#? In VB I can access it using the underscore _MyProperty. – Haytham Amairah Aug 24 '18 at 07:16
  • @HaythamAmairah I don't believe you can, not without reflection anyway. The backing fields are not nicely named like they are in VB, they follow the format `k__BackingField`, see [this question](https://stackoverflow.com/questions/8817070/is-it-possible-to-access-backing-fields-behind-auto-implemented-properties). – Ron Beyer Aug 24 '18 at 18:38
1

but I've noticed that the number1 property isn't exposed until I've created an instance of its class which is the same as if it was encapsulated in a getter and setter method like the number2 property!

Nothing is exposed before you create an instance of the class (not methods, fields nor properties)! This has nothing to do with getter/ setter or property... Just your basic OOP

The only Exception are methods/fields/properties with the "shared" keyword ("static" in c#)

Ryanless
  • 134
  • 1
  • 13
  • Thanks for the clarification, but what the benefit of the getter and setter while nothing can be exposed before we create an instance of its class? Is it the idea of hiding the field name and replacing it with a property name that can be only exposed when we create an instance of the class to act on behalf of the field itself? – Haytham Amairah Aug 23 '18 at 16:22
  • 1
    @HaythamAmairah : The getters and setters are there for all properties. If you don’t write them yourself them the compiler will generate them for you. They’re basically standard methods (a getter is equivalent to a `Function` and a setter is equivalent to a `Sub`). You write your own getters and setters when you want to do processing before returning the value, or before or after changing the value. Here’s an example: https://pastebin.com/uTtznXX2 – Visual Vincent Aug 23 '18 at 18:39
  • 1
    @HaythamAmairah : I think you’ve misunderstood the purpose of properties... Properties exist to help you control what data is passed from and to your classes/structures. The getters and setters are there so that you can impose restrictions on the data your class receives/gives out, _or_ to help you react to when a value is changed. For instance, when you change the image of a `PictureBox` through the `PictureBox.Image` property the code in the setter _not only_ updates the backing field, but it also calls `Invalidate()` which forces the `PictureBox` to redraw itself to display the new image. – Visual Vincent Aug 23 '18 at 18:55
  • @VisualVincent: Thank you so much for this explanation, it's really helpful! – Haytham Amairah Aug 24 '18 at 06:42