The NET Solution to Type Compatibility

One of the traits that distinguishes any great programming environment is a well thought out object model. It's difficult to work with a patchwork of poorly designed objects and continue to create world-class software. Given a good object model, you can easily extend it with your own code. The underlying support for the object model of the .NET Framework is the type system the framework offers.

Let me clarify a few terms here. When I talk about the type of a variable, I'm talking about what the variable is designed to hold. For example, if a variable is an integer type, you wouldn't expect that setting it equal to "dog" or "Fred" would work. Likewise, if the type were a date type, 7/24/1956 would be a reasonable value, but 7 wouldn't be. Classic Active Server Pages (ASP) programmers are used to a development language that doesn't use variables with types. More accurately, every variable is a single type: Variant. Thus, a variable can hold 7 in one line and "Fred" in the next. Many beginning programmers find having a single data type convenient, but more experienced programmers realize the mess that this limitation can cause. Although forcing you to explicitly change variables from one type to another can be more work, it does ensure that you're converting a variable in a way you intended.

Figure 3-1 shows the relationship between the various types the .NET Framework supports. Some of the types are probably familiar to you, and some refer to concepts that might be new to you, such as boxing and value types vs. reference types. I'll explain the new concepts associated with .NET Framework types as they come up in this chapter.

x iypa t

Viluft lypea flji'ci (irtid IJrtMi

Sijir.h valus (flMi flji'ci (irtid IJrtMi

Rainier lypaa

MtBfface

tytai

lip«

USBWfefilBtf ■,.sLfi lypii

Class lypc-t in

Arrays

Enunu«raikHi&

UsinnWirttS

fiiSHIS

typfls

CfHsBtHus

Figure 3-1 : The .NET Framework type system

Was this article helpful?

0 0

Post a comment