The methods of a class are just the public Sub or Function procedures you've declared. Since Sub and Function procedures are public by default, you don't even have to explicitly specify the Public keyword to create a method.
For example, to create a Withdrawal method for the Account class, you could add this Public Function procedure to the class module:
Public Function WithDrawal(ByVal Amount As Currency, _
ByVal TransactionCode As Byte) As Double
' (Code to perform the withdrawal and return the
' new balance, or to raise an Overdraft error.)
End Function
Tip Although you don't have to type the Public keyword, doing so is good programming practice, because it makes your intent clear to people maintaining your code later.
Returning the new balance is optional, since you could easily call the Balance property of the Account object after calling the Withdrawal method. You could thus code Withdrawal as a Public Sub procedure.
Tip If you find yourself calling Balance almost every time you call Withdrawal, returning the new balance will be slightly more efficient. This is because, as noted in "Adding Properties to Class Modules," any property access, even reading a public variable, means a function call — an explicit or implicit Property Get.
Important The following names cannot be used as property or method names, because they belong to the underlying IUnknown and IDispatch interfaces: QueryInterface, AddRef, Release, GetTypeInfoCount, GetTypeInfo, GetIDsOfNames, and Invoke. These names will cause a compilation error.
For More Information For more information on Sub and Function procedures, see "Introduction to Procedures" in "Programming Fundamentals."
The public interface of a class is defined by the property and method declarations in the class module. As with data hiding, procedures you declare as Private are not part of the interface. This means that you can make changes to utility procedures that are used internally by a class module, without affecting code that uses the objects.
Even more important, you can also change the code inside the public Sub or Function procedure that implements a method, without affecting code that uses the method. As long as you don't change the data types of the procedure's arguments, or the type of data returned by a Function procedure, the interface is unchanged.
Hiding the details of an object's implementation behind the interface is another facet of encapsulation. Encapsulation allows you to enhance the performance of methods, or completely change the way a method is implemented, without having to change code that uses the method.
Note The guidelines for naming interface elements — discussed in "Naming Properties, Methods, and Events" — apply not only to property and method names, but to the names of parameters in the Sub and Function procedures that define your methods. These parameter names are visible when you view the methods in the Object Browser, and can be used as named parameters (that is, parametername:=value) when the methods are invoked.
For More Information Named arguments are introduced in "Passing Arguments to Procedures" in "Programming Fundamentals."
Adding methods to form classes is a powerful programming technique, discussed in "Customizing Form Classes."
Sometimes it's not clear whether a member should be a property or a method. "Is It a Property or a Method?" offers some guidelines.