The .NET Object

To fully understand software development in .NET, you must understand what an object is. (If you are familiar with object-oriented programmingOOPthen you can probably skip down to the next section, although you will miss some really great content.) Although some of this section's information will also appear in Chapter 8, "Classes and Inheritance," it is so important to the discussion of .NET that a portion appears here as well.

Objects and Data

From a programming standpoint, a computer performs four basic tasks:

1. It stores data in the computer's memory area.

2. It supports processing of this data through basic operations, including addition and subtraction, Boolean algebra, and text string manipulation.

3. It allows the user to interact with the data stored in memory.

4. It provides a way to bring the data in and out of memory, through input and output devices such as keyboards and printers, and through long-term storage media, such as hard drives.

The core of these four activities is data. Computers exist to manipulate data. Operating systems provide the basic foundation for these activities, but it is software applications that make these featuresthe ability to manipulate datareal and meaningful to the user. High-level programming languages are the primary tools used to develop these applications, each of which uses some general methods to make data manipulation features available to the programmer. Back in the good old days of assembly language development, if you knew the memory address of a piece of data, you could access and manipulate it directly. In early flavors of BASIC and in most other "procedural" languages, data was accessed through variables.

As languages grew in complexity and purpose, so did their view of data. In the LISP (short for "List Processing" or "Lots of Irritating Silly Parentheses") language, any data value exists within a larger list or set of data. But in .NET languages, data is viewed through the object.

Objects are collections of data values and associated source code. Whereas in older BASIC dialects, each data element was more or less independent through its named variable, related data values in OOP languages can be grouped into objects. Objects often include source code designed to manipulate the data values of that object.

Objects generally represent some thing, often a thing that has a real-world counterpart, whether physical or conceptual. For instance, your code may include a House object that has data fields or properties for the address, the exterior paint color, and the number of people living in the house. Associated source code could manage that data; a Paint method could alter the color value used for the exterior paint.

The data and code elements within an object are called members. Some members are hidden inside the object and can be accessed only by the object's source code. Other members are more public; any code in your application can use them, not just that subset of application code found inside the object. Consider a television as an object (see Figure 1-1).

Figure 1-1. A TV: It's an object, not just objectionable

The public members of a TV are generally easy to use: the power button, channel selector, volume control, and so on. They are the conduits through which the user controls the data values of the TV (its video and audio output). There are also hidden members inside of the TV; you could use these members to impact the picture and sound quality, although this would be a bad idea for most users. You don't want me messing with the internal members of your TV set, trust me. In the same way, an object doesn't want code outside of the object to mess with its internal members except through the public members. I don't care how a TV works internally, as long as I can get pictures and sound out of it by using the controls that are exposed (power, channel, volume).

Objects and Interfaces

The public members of an object represent its interface. If code outside of the object wants to manipulate the data belonging to that object, it uses the members of the interface. It doesn't have to figure out the hidden members or how they work, and that's good. It's especially good if those internal members ever change for any reason, which happens more often then you think. Consider how the internals of TVs have changed just in the last 30 years. Here's a drawing of the TV my family had when I was a kid. Compare it with modern flat-screen TVs available today (see Figure 1-2).

Figure 1-2. Are those really TVs?

My family's TV was cool. It had an AM/FM stereophonic hi-fi radio, a turntable that could play 33-1/3, 45, and 78 RPM records, and a large 19-inch display with vivid black-and-white crystal-clear display. You could hide two kids behind it when playing hide and seek. And my friend who had the same model said that you could draw these really cool permanent lines on the screen with a magnet. Who cares that the speaker panels looked like vertical shag carpet? Who cares that the unit took up 30 percent of the floor space in the room? Who cares that you could cook sausages on top of it from the heat generated by the vacuum tubes? It was more than a TV; it was an entertainment center.

Now compare it to the wimpy little flat screen job on its right. If you look closely, you find that the interface to the TV hasn't really changed much in three decades. There are still controls for power, volume, and channel selection (although Horizontal Hold and Vertical Hold are gone, sniff). What has changed is the internal configuration. Gone are the humming vacuum tubes, all replaced with efficient transistors and solid-state components. But it doesn't really make much difference to the TV viewer, because the public interface remains the same.

Objects in OOP development work in the same way. As long as the public interface remains the same, the object's actual code and internal data storage systemalso known as the object's implementationcan change with no impact to the overall application.

Objects and Instances

The interface and implementation of an object really only represent its design; these are the parts created through the source code. They exist even before the program is compiled and installed on the user's computer. In fact, at this level, objects really aren't even known as objects. In most languages (including Visual Basic), the word class indicates the implementation of an object's interface.

Once your application is installed on a computer and starts up, the code creates instances of the class to store actual data in memory. These instances are the true objects of OOP development. Depending on how your code is written, a single class implementation might create just one or hundreds of objects in memory at the same time.

In .NET, all of your code and data values appear inside of objects. Pretty much everything you see in a running program is an object: Windows forms are objects; a list box control on that form is an object; and a single item in that list box is an object.