Creating Class Methods
Class modules have subs and functions, but to give the impression that they're somewhat special, they're called methods. It makes some sense when you consider that a class's procedures carry out actions on its properties, and therefore, constitute the method by which those actions are executed.
In the same way that methods are executed against objects in the Access object model, class methods are executed against class objects. For example, to move a DAO recordset cursor to the next record, you are actually using a method exposed by the Recordset class.
rst.MoveNext
There are three types of methods: sub(routine)s, functions, and properties. Subs and functions you know about, but properties, which will be introduced a little later, are special types of methods that can exhibit the characteristics of both.
Subs, functions, and properties of a class are also known as members of the class.
To create an external interface for your class, you need to add subs, functions, and properties. Let's take a closer look at the clsClassroom class.
Option Compare Database Option Explicit
Private mintStudents As Integer
Public Sub AddStudents(intHowMany As Integer)
'Make sure we don't receive a negative number If intHowMany > 0 Then mintStudents = mintStudents + intHowMany End If End Sub
Public Function GiveTest() As Boolean
'Code to implement the GiveTest action. If AllStudentsPresent() = True Then 'code to administer a test GiveTest = True End If End Function
Private Function AllStudentsPresent() As Boolean
'Code to determine if all students are present. 'For our example, we'll just return True. AllStudentsPresent = True End Function
Public Property Let Students(intNewValue As Integer)
mintStudents = intNewValue End Property
Public Property Get Students() As Integer
Students = mintStudents End Property
In this class module, you have a private integer variable called mintStudents, declared at module-level so all your procedures can access it. You also have a public sub procedure called AddStudents, a public function called GiveTest(), a private function called AllStudentsPresent(), and two Property Procedures, both called Students (I'll explain in a moment).
The AddStudents method takes a single integer argument that specifies the number of students to add to your classroom. Nothing special there. The GiveTest method takes no arguments, but returns a Boolean value indicating success or failure. You might also notice that GiveTest executes some code to actually administer the test, but only if the AllStudentsPresent() function returns True. Once the students have had their test, GiveTest returns True to the code that called it.
You've probably already noticed that you seem to have duplicate procedure names. You do, but property procedures are a special type of procedure for which duplicate names are allowed. But before you explore property procedures, it's appropriate to first understand a term that is often used to describe the object properties and methods that are visible and accessible to the VBA code that instantiated the object: the interface.
Having already mentioned the class interface, it may be worthwhile digressing a little to offer an explanation before you proceed with property procedures. Simply put, an interface is the set of Public properties and methods in a class. Much like any VBA procedure, the Public members of the class are available to other code running outside the class, whereas Private members are only available inside the class. In the example shown in the preceding section, the interface is defined by those methods and procedures declared as Public. Code outside the class cannot see private members, and therefore, cannot execute them. Therefore, properties and methods declared as Private are not part the interface of your class.
In the following example, the PrintPayraise() procedure is part of the object's interface, while GivePayraise() is not. It's that simple!
|
Public Sub PrintPayraise() | |
|
'Public methods are part |
of the object's interface. |
|
End Sub | |
|
Private Sub GivePayraise() | |
|
'Private methods are not |
part of the object's interface. |
|
End Sub |
When creating classes, it is very important that you maintain the integrity of its interface. That is, you should avoid changing the names of properties, methods, or any arguments. Also, avoid changing the number of arguments or their data types. Programmers go to a great deal of trouble to write VBA code to instantiate and use a class object that has a specific interface, so if you change that interface, you break the very thing that VBA code needs to make it all work.
On large software projects, where many developers are working on different parts of the system, a single changed interface can result in many weeks of lost time while everyone changes their code. Rarely does this make for a happy team.
The rule in most software development houses is "never break an interface!" If you need to make changes that will result in the need to change large sections of VBA code, either create a new class or add new methods to the existing one. Existing code continues to use the existing interface, whereas newer code that needs to take advantage of any new or modified functionality can use the new ones.
Post a comment