So if I had 2 private classes, each containing a private variable named cost
would this work fine or should I use different variable names?
That will work fine. Private variables are only accessible from within the class, so there's no scope for ambiguity.
Related
I am bit confused over the need to use GET & SET methods in VB.net. I want to discuss two cases in this connection: firstly when we declare the property as PUBLIC and next when we declare the property as PRIVATE.
What is I find is when I define a property as public I can directly set and access the values of that property without using the GET/SET methods --- quite simple: See below
Module Program
Sub Main()
Dim t As New test()
t.name = "Roy" 'Label 1
Console.WriteLine("t.name = {0}", t.name)
Console.ReadLine()
End Sub
End Module
Class test
Public Property name() As String
End Class
When I declare that same property as private, as shown below, I can still set and access the value of private property by simply using a constructor and a public subroutine. See below:
Module Program
Sub Main()
Dim t As New test()
t.printValue()
Console.ReadLine()
End Sub
End Module
Class test
Private Property Name() As String
Sub New()
Name = "Roy" 'Label 2
End Sub
Public Sub printValue()
Console.WriteLine("Value stored in NAME is: {0}", Name)
End Sub
End Class
So my question is why at all do we need to use the GET/SET methods? I understand that whenever an assignment happens to a property the SET method is implicitly called...but can you please help me understand cases where we MUST explicitly use the GET/SET methods? Or it is that using GET/SET is more of a choice? Validation is one thing that can be added easily at a later stage if one uses GET/SET but then is that the only reason? PLs give your views.
Also, I came across the following two related questions in stackoverflow (for different languages though): Links below:
Why to use getter and setter methods to set class properties?
Why use getters and setters/accessors?
But i could not understand most of the reasons justifying the usage of the GET/SET methods. For example if we dont use the GET/SET method then we are exposing the property to the outside world - meaning it can be directly accessed from outside the class. But then this is true only for PUBLIC properties as PRIVATE properties cannot be directly accessed from outside the class. Similarly in the second link the author mentions the following as a reason to use GET/SET: Providing a debugging interception point for when a property changes at runtime - debugging when and where a property changed to a particular value can be quite difficult without this in some languages. What exactly does this mean --- any simple real life example?
A property is a wrapper around a field, i.e., a class or struct variable. It provides a getter and/or a setter method to access this variable. (You can also have a read-only property returning the result of a simple evaluation not bound to a single field.)
The getters and setters are implicitly called when reading from, respectively writing to properties.
So, the question is not whether to use getters and setters or not, but whether to access fields directly or via a property.
You can declare a property like this, by declaring a field and writing the getter and setter explicitly.
Private _prop1 As String ' Backing field
Public Property Prop1() As String
Get
Return _prop1
End Get
Set(ByVal value As String)
_prop1 = value
End Set
End Property
or use an Auto-Implemented Property
Public Property Prop1 As String
Both declarations are equivalent. The auto-implemented property implicitly declares a backing field and implements the getter and the setter accordingly.
It can make sense to declare a property as private when you use it only inside the class where it is declared. This still provides the advantages described in the links you provided because this property still hides the details of accessing a field, does validations, etc.; however, it does not forbid the direct access to the backing field inside the class. So, you need to be more disciplined with private properties.
What does a property mean for debugging? You can easily set a breakpoint inside a getter or setter to detect accesses to a property. You cannot set a breakpoint on a field because a field is never executed. It is just a declaration.
You can also add a System.Diagnostics.Debug.Writeline("=====> test") (writes to the Output window) or do some logging in getters and setters.
See also: Tutorial: Learn to debug Visual Basic code using Visual Studio
When using Windows Forms Data Binding or WPF Data Binding properties are required. They also allow change notification.
Dynamically Calculated Values
I didn't read those links, but one reason you might want to implement your own getters & setters is that you may want to return something that requires some type of calculation or manipulation. For example, suppose you have item Sale with properties RawPrice, SalesTax, and FinalPrice. However, you need/choose to dynamically calculate the final price (based on variable sales tax) each time. So you first set the RawPrice, and then query FinalPrice, which returns RawPrice + SalesTax, but SalesTax gets dynamically calculated based on some other property like country of origin etc.
Alternate View of Data
Another reason you might want to do this is to provide another view of the same core data. For example, if your data was an HTML page, perhaps one property returns the normal string value, while another "no-HTML" Property has a custom Getter that performs some regex to remove all HTML tags and return a plain-text variation. This allows you to keep all related code inside of a sub-assembly, rather than having your main program do various manipulations.
Code Portability
This can make your life a lot easier down the road because of code portability. Your code is now more easily re-usable in other projects, since all you need is that one assembly.
Private Variables vs Properties
If I'm doing something that calls for a class with properties like that, there's good chances it's going to have methods, too. Those methods are almost always going to require creating private variables that nothing outside the assembly needs to know about. However, in such cases, they are not going to be private properties but rather simply private variables. For example, instead of Private Property Name() As String, with its implied auto-implemented backer variables with getters & setters, I would instead just say Private Name() As String, which would be equivalent to Dim Name() As String. You can use variables, constants etc. within your class just as you normally would, and, by default, the rest of the world won't know anything about them.
I'm not sure why you'd use a private Property. Maybe there's a good reason; I just don't know what it is. Most of the time, a private variable is probably what you really want. If you think there's a reason that you actually need a Private Property, I'm curious to hear your thinking on it. (I'm always open to a new way of thinking!)
History
Auto-implemented properties were not present in Visual Basic .NET for many years. In the past, you had no choice but to use GET/SET. So it's a more recent development for VB.NET to be able to simply declare a property as you do in your first code example, and for the runtime to automatically generate the backer variables.
What would be an underlying difference in the following aspects of the ensuing two subs:
Scope of the subs? (This question primarily applies to the second
routine)
Scope of the variable declarations within?
Application of one vs another?
1:
Sub test1()
Static x As Byte
x = 1
End Sub
2:
Static Sub test2()
Dim y As Byte
y = 2
End Sub
Making the entire procedure Static is a shortcut for declaring all its local variables Static.
So there is effectively no difference between the subs, because effectively all their local variables are declared as Static and as such are preserved between the calls.
But as in both subs you manually overwrite the value to something else right after the variable declaration, the effect of preserving the value does nothing for you.
There is no difference in the scope of the subs (it remains what it was before Static), or the the scope of the local variables (they remain local).
In VBA for Access, how do I make a global variable that I can access and change anywhere?
You can declare a variable at Global scope by declaring it in a Standard Module or a predeclared class module such as a Worksheet, UserForm or PreDeclared class, using the Public keyword:
Public myVar As String
You can also declare a Global variable using the now deprecated, but still valid Global syntax, which is functionally the same as Public
Global myVar As String
But note that declaring a variable with Public or Global will make the variable accessible across your entire project AND to any project that refers to that project, and even if your project is protected, a user could still query the variable from the Immediate window.
If you must have a variable that is available across your project, but only that project, then you should declare the variable in a standard module, and include an Option Private Module statement to make the module private to the project, but its variables as Public to the project only.
Option Private Module
Public myVar As String
I have a Global Variable called EmployeeID. I set this by calling a function:
Global EmployeeID As Integer
Public Sub init_Globals(emp As Integer)
EmployeeID = emp
End Sub
On the main form, I used:
MsgBox EmployeeID
from a button and it works just fine; but the funny thing is when I use this from a subform it returns a 0:
I might add that this is a Continuous Form as well.
Private Sub cboWhichDate_AfterUpdate()
Me.txtEmployee = EmployeeID
End Sub
A "global" variable can only be "global" if its scope is global. Sticking a Global access modifier to a field declared in a class module doesn't make it global.
In fact, the Global keyword is deprecated, and is completely replaced/superseded by the Public access modifier.
What matters is the variable's scope. If that declaration is located in a class module (a form's code-behind is essentially a class module), then all you've done is declare a public instance field; you can only access the value via the object instance that owns it.
Dim MyObject As New MyForm
MyObject.EmployeeID = 42
MsgBox MyObject.EmployeeID
To make a global variable, add a standard module (.bas) to your project, and declare it there.
Public EmployeeID As Integer
Now everyone everywhere can access EmployeeID, because it's scoped to a module (i.e. not an instance of an object), and its accessibility is public.
That said, global variables are evil and can easily lead to unmaintainable spaghetti code; Consider passing values as parameters instead.
I have been looking at a class that has a method that accepts a parameter that is of the same type of the class containing the method.
Public Class test
private _avalue as integer
Public Sub CopyFrom(ByVal from as test)
_avalue = from._avalue
End Sub
End Class
When used in code
a.CopyFrom(b)
It appears that instance "a" has visibility to the private members of the passed in instance "b" and the line
_avalue = from._avalue
runs without error copying the private field from one object instance to the other.
Does anyone know if this is by design. I was under the impression that a private field was only accessible by the instance of the object.
The private scope is related to the type not the instance. So yes, this is by design.
The class test has knowledge about the private parts of itself, so it can use those parts also on other instances of the same type.
You are writing something similar to to a copy constructor.
Since the copying method/function is being written inside of the same class, it will have access to private variables of any instance of its own class.