properties

Steve36445

Well-known member
Joined
Dec 23, 2007
Messages
58
Programming Experience
10+
Can you help me please?

I am trying to get my head around classes.
As far as I can make out the recommended way of getting include data to and from a class is as follows. It works fine but it seems very complicated to me.

VB.NET:
Private fn As String

 Public Property file_name() As String
        Get
             Return fn
        End Get

        Set(Value As String)
            fn = Value
        End Set

Accessed by-

VB.NET:
Label1.Text = source_obj.file_name

Can anyone please explain to me why I cannot just declare a public variable in the class and access it from calling form as below.

Class-
VB.NET:
Public file_name as string

form-
VB.NET:
Label1.Text = source_obj.file_name

or-

VB.NET:
source_obj.file_name= Label1.Text

many thanks,

Steve
 
Properties are kind of procedures, they allow access to/from object state (fields) which should be protected from direct outside access. With properties you can have multiple statements when the value is get/set, events can be raised etc. Properties can be get/set or just either one. The value/object returned can be computed when the property is accessed. Properties can be used in data binding to controls. They can take part in inheritance and interfaces.
Property Procedures (Visual Basic)
Differences Between Properties and Variables in Visual Basic

Properties can be declared almost the same as fields in many cases: Auto-Implemented Properties (Visual Basic)
 
thanks John,
it is probably a bit beyond me.
whilst I am reasonably well educated, I program for my own use and as such do not have to worry about anyone following my code.

My take would be that the "proper way" is probably more flexible.
You suggest what the "proper way" can do that do but don't suggest why I should not use the other the way, I guess this is convention and flexibility.

If the other way is doing what I wish is there any reason why I should not use it?
thanks again.
Steve
 
Properties basically exist to provide the functionality of a field from the outside, i.e. simple get and set, while providing the functionality of methods from the inside, i.e. do whatever you like when that property is got or set.

If fields are doing what you need then there is no reason not to use fields other than adhering to good practice and consistency. The thing is, with auto-implemented properties, there is basically no extra work to declaring a property over a field so there's no good reason not to do it. There will undoubtedly be times where you specifically need a property and to then have some members implemented as properties and some as fields creates inconsistency and can therefore be a source of confusion. Properties can be bound where fields can't so there is also the possibility that you could wind up needing to bind a type and not be able to because you chose not to declare a property for no good reason. Good practice is considered good practice for a reason. There can be pragmatic reasons to veer from it at times but there is no pragmatic reason to use fields over properties, only dogmatic reasons.
 
hi John,
that makes things a lot clearer, thanks.
Now if you can just explain why the answer to the meaning of life is 42 I can die happy..

Thanks again,

Steve
 
Back
Top