The second type of member that an objects can have is called a shared member. The syntax for shared members is different. In particular, you don't have to create an instance of the object in your code to use a shared member. One of the best examples of shared methods can be found in the Math class that is part of the .NET Framework. Enter Math. in the VB.NET editor to see all of the methods and properties available. To take advantage of shared properties and methods, just code the object and the member directly. For example, to get the trigonometric tangent of a 45 degree angle:
MsgBox(Math.Tan((Math.PI / 180) * 45))
This give you the value 1. Note that the Math object trig functions have to be expressed in radians so both the shared property PI, to convert from degrees to radians, and the shared method Tan had to be used.
Shared properties are much less common than shared methods and it's not likely that you'll code very many in your own programs. The reason is that there are usually no constant values that are always the same whenever an object is used. One classic example of a shared property is the collection of connection parameters for a database when the code for an object needs to query a database. Since they're usually constant, these connection parameters for the call are often shared properties.
Here's a simplified example of a class that uses both shared properties and methods.
Suppose you had a class that was used to query an inventory database. A common requirement for the class would probably be to return the current inventory. This method doesn't require any parameters and would be the same for all programs. Note that the qualifications for the Function statement are the major difference.
Public Shared Function CurrentInventory() As Integer
' A database call would probably be
' coded in this method.
' For our purposes, we'll stub
' the method with a constant value.
CurrentInventory = 12345
End Function
But when might a shared property be useful? Another example might be a system where programs normally use inventory for a particular database. The database used could be enforced by coding the name as a shared property. (There are other ways to solve this problem too and I'm not claiming this is the best one.) One advantage (or disadvantage, since it falls into a category of a "hidden" function of the program) is that the database actually used depends on the version of the object library included. Different versions could reference different databases.
Public Shared ReadOnly Property DBName() As String
Get
Return "FunnyNumbers_DB_for_the_auditors_only"
End Get
End Property
You can reference the properties and methods for this custom object just like the ones in the .NET Framework:
MsgBox(Inventory.DBName)
MsgBox(Inventory.CurrentInventory)
It's just like you learned as a child, "It's good to share."
