The Employee Class Properties

The Employee Class Properties

Properties are the gatekeepers for our private data fields, such as m_iEmpNumber. I mentioned earlier that these variables are instance variables. Each instance of the object has its own m_iEmpNumber.

Let's say that you draw two buttons on a form and you set the Text property of the first to Hola and the second to Adios. While both buttons are instances of the same button class and live in the same DLL, each button is a unique object instantiated in memory. Each has its own individual Text property and Location property set to something different. Likewise, each instance of our Employee class has its own value for the private data field iEmpNumber.

Private m_iEmpNumber As Integer = 0

If this Employee class data field is private, how can it be read from or written to? That's where properties come in. We provide access to our private variables only through properties. By doing this, the class instance variables can't be changed accidentally or maliciously.

Think of your house as a class. Even though you have windows in the house, you permit access only through the door. Someone could crawl into the house through a window, of course, but you can lock it so that such access is not allowed. By forcing all access to the house through the door, you can do things such as put a doormat on the floor so that visitors can wipe their feet, or you can lock the door when you're not at home. You control access to the house.

Properties control access to your classes' private data fields, which permits you to validate or edit any data that's passed in. You can place business rules in the property to ensure that data falls within your predefined rules.

A data field usually has a Get property that returns a value to the world outside the class and a Set property that's used to take a value in from the outside and assign it to a private variable. Properties that can be accessed from outside your class must use the Public access modifier.

The control that properties provide gives a programmer flexibility. As I mentioned, you might want to edit or validate data within a property before you assign it to the data field. Or, in the case of the Employee class's m_iEmpNumber variable, you want users to be able to read the number but not change it. That restriction is easily accomplished by using the ReadOnly access modifier. If you want a property to be write-only, you use the WriteOnly access modifier. Notice that in our example, the return value is an integer, as defined by the property's signature.

Public ReadOnly Property EmployeeNumber() As Integer     Get         Return m_iEmpNumber     End Get End Property

Most properties permit private data instance variables to be either read from or written to from outside the class. For example, we can either get (read) the string FirstName or set (write) a new value from the outside and assign it to the m_sFirstName private data field. Unlike Visual Basic 6, in which the value to be written is explicitly passed into the property, Visual Basic .NET uses the new Value keyword. The type of the keyword is defined in the signature of the property. In our example, only a string data type can be passed into the property as a value.

Property FirstName() As String     Get         FirstName = m_sFirstName     End Get     Set         m_sFirstName = Value     End Set End Property

If a program wanted to use our Employee class, the code might look something like this.

Dim newEmp1 As New employees.Employee()          With newEmp1     .FirstName = "Garrett"     .LastName = "Connell"     .VBNet = True  End With

The class is created with the New keyword, and a reference to the newly minted object is given to the reference variable newEmp1. We can then set the FirstName, LastName, and VBNet properties by simply assigning values to them.

From the outside, nothing reveals that the FirstName property really sets a private variable, m_sFirstName. That's another benefit of using properties: the outside world does not need to know or care how the property is implemented within the class. For example, when you set a button's Text property, you have no idea how this is done, but who cares? How it's done is not important to us. We want to use the black box functionality of the button class. Likewise, a user of our Employee class doesn't care how we implement the property; it's only important that it can be set and read.

	We could have written the preceding property assignment code by fully qualifying each property using Object.Property = Value. newEmp1.FirstName = "Garrett" newEmp1.LastName = "Connell" newEmp1.VBNet = True Whenever you have two or more properties you are reading or writing, your code will execute more quickly if you use the With Object / End With syntax. When Visual Basic .NET sees a dot ("."), it must take time to resolve it. The With statement allows you to perform a series of statements on a specified object without requalifying the name of the object. Once a With block is entered, the object can't be changed. As a result, you can't use a single With statement to affect a number of different objects.

Another benefit of using properties and methods is that if we don't change the interface contract (i.e., the signature of the property or method), we can update and modify the implementation of the property or method and the outside world will never know. You might later want to add additional business rules or stricter validation based on what users enter. Simply add the new code and recompile the assembly, and the calling program will be none the wiser because we changed the implementation and not the interface to the outside world. The objective is to not break any programs that call and use our object.

Building a class is like a legal contract. You set out certain conditions (properties and methods) that the class user abides by. Once set, these conditions can't be changed. A contract like this was a fundamental rule of COM for Visual Basic 6 and still applies in Visual Basic .NET. You can add procedures, methods, or properties in newer renditions of a class. However, you can never change any methods or properties that have already been published—these interfaces to our class are sacrosanct. Any legacy programs that might use your object will continue to work without being affected, and newer programs can take advantage of the functionality you added in later releases of your class.

Take a look at the assignment of the FirstName property in our object. Because the property is on the left side of the equal sign, the compiler recognizes that it should invoke the Set portion of the property. If we wrote a statement like sString = newEmp1.FirstName, the compiler recognizes a read operation and invokes the Get portion of the property. All we do is provide Get and Set code. The compiler does the heavy lifting in determining which one to use.