In general, a property is data about an object, while a method is an action the object can be asked to perform. Some things are obviously properties, like Color and Name, and some are obviously methods, like Move and Show.
As with any facet of human endeavor, however, there's a gray area in which an argument can be made either way.
For example, why is the Item method of the Visual Basic Collection class a method and not an indexed property? Aren't the items in the collection just data? The Item method of a hypothetical Widgets collection class could be implemented either way, as shown here:
' Private storage for the objects in the Widgets
' collection (same for both implementations).
Private mcol As New Collection
Public Property Get Item(Index As Variant) As Widget
Set Item = mcol.Item(Index)
End Function
- or -
Public Function Item(Index As Variant) As Widget
Set Item = mcol.Item(Index)
End Function
There's not a whole lot of difference between these two implementations. Both are read-only, so both depend on the Add method of the Widgets class to get Widget objects into the collection. Both delegate everything to a Collection object — even their errors are generated by the Collection!
For More Information Delegation is explained in "The Many (Inter)Faces of Code Reuse" and "Creating Your Own Collection Classes" later in this chapter.
You can get really nit-picky trying to decide whether a member is data about the object or object behavior. For example, you could argue that Item is a method because the collection is doing something for you — looking up the Widget you want. This kind of argument can usually be made with equal validity on either side, however.
You may find it more useful to turn the argument on its head, and ask yourself how you want to think of the member. If you want people to think of it as data about the object, make it a property. If you want them to think of it as something the object does, make it a method.
A strong reason for implementing a member using property procedures depends on the way you want to use the member in code. That is, will the user of a Widgets collection be allowed to code the following?
Set Widgets.Item(4) = wdgMyNewWidget
If so, implement the member as a read-write property, using Property Get and Property Set, because methods don't support this syntax.
Note In most collection implementations you encounter, this syntax is not allowed. Implementing a Property Set for a collection is not as easy as it looks.
You can also suppose for a moment that your object is like a control. Can you imagine the member showing up in the Property window, or on a property page? If that doesn't make sense, don't implement the member as a property.
If you forget that you made Item a read-only property and try to assign a value to it, you'll most likely find it easier to understand the error message Visual Basic raises for a Property Get — "Can't assign to read-only property" — than the error message it raises for a Function procedure — "Function call on left-hand side of assignment must return Variant or Object."
As a last resort, flip a coin. If none of the other arguments in this topic seem compelling, it probably doesn't make much difference.
For More Information Property procedures are introduced in "Adding Properties to Classes" earlier in this chapter. Methods are discussed in "Adding Methods to Classes."