Instantiating Objects from Classes
After you obtain a reference to an object and assign it to a variable, you can manipulate the object using an object variable. You're going to do this now.
Click the Form1.cs Design tab to view the form designer and add a button to the form by double-clicking the Button item in the toolbox. Set the button's properties as follows:
Next, double-click the button to access its Click event and enter the following code:
clsMyClass objMyObject = new clsMyClass(); MessageBox.Show(objMyObject.AddTwoNumbers(1,2).ToString());
The first statement creates a variable of type clsMyClass. (Declaring variables was discussed in Hour 12, "Using Constants, Data Types, Variables, and Arrays.") The new keyword tells C# to create a new object, and the text following new is the name of the class to use to derive the object (remember, classes are object templates). The last statement calls the AddTwoNumbers method of your class and displays the result in a message box after converting the return value to a string.
Notice that C# displayed an IntelliSense drop-down list with all the members of the class (see Figure 17.4).
Figure 17.4 C# displays IntelliSense drop-down lists for members of early-bound objects.
Go ahead and run the project by pressing F5, and then click the button to make sure everything is working correctly. When finished, stop the project and save your work.
Binding an Object Reference to a Variable
An object can contain any number of properties, methods, and events; every object is different. When you write code to manipulate an object, C# has to understand the interface of the object or your code won't work. Resolving the interface members (the properties, methods, and events of the object) occurs when an object variable is bound to an object. The two forms of binding are early binding and late binding. In addition, binding can occur at runtime or at compile time. It is important that you have at least a working understanding of binding if you are to create code based on classes. Although I can't explain the intricacies and technical details of early binding versus late binding in this hour, I will teach you what you need to know to perform each type of binding.
Benefits exist to both types of binding, but early binding is generally superior to late binding because code that uses late-bound objects requires more work (time and resources) by C# than code that uses early-bound objects.
Late Binding an Object Variable
When you declare a variable using the generic data type Object, you are late binding to the object.
Unfortunately, C# requires you to handle additional details when late binding to an object (unlike Visual Basic, which handles the details for you). Late binding is beyond the scope of this book, so I'll be focusing on early binding in this hour.
Late binding requires a great deal of overhead, and it adversely affects the performance of an application. Therefore, late binding isn't the preferred method of binding. Late binding does have some attractive uses; however, most of these are related to using objects outside your application, not for using objects derived from classes within the project.
One of the main drawbacks of late binding is the inability for the compiler to check the syntax of the code manipulating an object. Because C# doesn't know anything about the members of a late-bound object, the compiler has no way of knowing whether you're using a member correctlyor even if the member you're referencing exists. This can result in a runtime exception or some other unexpected behavior.
As explained in the previous hour, runtime exceptions are more problematic than build errors because they're usually encountered by end users and under varying circumstances. When you late bind objects, it's easy to introduce these types of problems; therefore, a real risk exists of throwing exceptions with late binding. As you'll see in the next section, early binding reduces a lot of these risks.
Early Binding an Object Variable
For a member of an object to be referenced, C# must determine and use the internal ID of the specified member. You don't have to know this ID yourself; just be aware that C# needs to know the ID of a member to use it. When an object is early bound (declared as a specific type of object), C# is able to gather the necessary ID information at compile time. This results in considerably faster calls to object members at runtime. In addition, C# can validate a member call at compile time, reducing the chance of errors in your code.
Early binding occurs when you declare a variable as a specific type of object, rather than just as object.
The following are important reasons to use early binding:
Objects, their properties, and their methods appear in IntelliSense drop-down lists.
The compiler can check for syntax and reference errors in your code so that many problems are found at compile time, rather than at runtime.
For early binding to take place, an object variable must be declared as a specific object type.
Releasing Object References
When an object is no longer needed, it should be destroyed so that all the resources used by the object can be reclaimed. Objects are destroyed automatically when the last reference to the object is released. Be aware, however, that objects aren't necessarily destroyed immediately when they are no longer referenced and that you don't have control over when they are destroyed. In Hour 24, you'll learn how the garbage collector cleans up unused objects. In this hour, I'm going to focus on what you should do with an object when you're finished with it.
One way to release a reference to an object is simply to let the object variable holding the reference go out of scope, letting the garbage collection of .NET regain the memory space.
To explicitly release an object, set the object variable equal to null, like this:
objMyObject = null;
When you set an object variable equal to null, you're assured that the object reference is fully released. However, just because the reference is released does not mean the object is destroyed! The garbage collector will periodically check for unused objects and reclaim the resources they consume, but this may occur a considerable length of time after the object is no longer used. Therefore, you should add a Dispose() method to all your classes. You should place clean-up code within your Dispose() method and always call Dispose() when you are finished with an object. One thing to keep in mind is that it is technically possible to have more than one variable referencing an object. When this occurs, calling Dispose() may cause clean-up code to execute and therefore cause problems for the code using the second object variable. As you can see, you need to consider many things when programming objects.
If you don't correctly release resources used by your objects, your application may experience resource leaks, may become sluggish, and might consume more resources than it should. If your object uses resources (such as memory or hardware resources), you should implement a Dispose() method. In addition, you should always call the Dispose() method of an object you are finished with if the object has implemented a Dispose() method.
Understanding the Lifetime of an Object
An object created from a class exists until the garbage collector (see Hour 24) determines it is no longer used and then destroys the object. Fortunately, C# (or more specifically, the .NET Framework ) handles the details of keeping track of the references to a given object; you don't have to worry about this when creating or using objects. When all the references to an object are released, C# destroys the object. Your primary responsibility for destroying objects is to call Dispose() on any objects that you are finished with and to create a Dispose() method for your own classes that use resources. Beyond that, the garbage collector handles the details of destroying the objects.
An object is created (and hence referenced) when an object variable is declared using the keyword new (for example, clsMyClass objMyObject = new clsMyClass();).
An object is referenced when an object variable is assigned an existing object (for example, objThisObject = objThatObject;).
An object reference is released when an object variable is set to null (see the section "Releasing Object References") or goes out of scope.
When the last reference to an object is released, the object becomes eligible for garbage collection. Many factors, including available system resources, determine when the garbage collector executes next and destroys unused objects.