Chapter 2: Types

Overview

Types are the places, persons, and things of an application. As part of the object design, scenarios are often drafted as a "day in the life" of a problem domain. The scenarios are mined for nouns, which become potential future classes. Object-oriented programs model real-world problems, in which types represent identities from your problem domain. An employee in a personnel program, a general ledger entry in an accounting package, and geometric shapes in a paint application are examples of types. Types include reference types, value types, and unsafe pointers. The topic of unsafe pointers is included in Chapter 14, "Memory Management."

A reference type refers to an object created on the managed heap, and the lifetime of the resulting object is controlled by garbage collection services provided by the Common Language Runtime (CLR). The reference holds the location of an object created on the managed heap. Reference types derive from System.Object implicitly and are created with the new keyword. The archetypal reference type is a class. Other reference types are interfaces, arrays, and delegates.

Value types are lightweight components that are placed on the stack. Value types directly contain their value. Value types are customarily created statically. For custom initialization, a value type can be constituted using the new statement. This does not fabricate a value type on the managed heap. It still resides on the stack. Value types derive from System.ValueType, which is derived from System.Object. System.ValueType defines a value type by rewriting most of the semantics of System.Object. Primitives such as int, float, char, and bool are archetypal value types. As a primitive, a string is a hybrid. Strictly speaking, strings are reference types. However, strings have some of the characteristics of a value type. Structures and enumerations complete the list of value types.

Classes and structures are the primary focus of this chapter. A class or structure is a blueprint for creating components of similar behavior and attributes. A class instance is called an object, whereas an instance of a structure is a value. An Employee class would describe the common attributes and behavior an employee. A Fraction structure would calculate fractions. Each instance of an Employee or a Fraction shares common behavior with their siblings but has a distinct state. Within a classification of objects, the GetHashCode method returns a unique value that distinguishes a specific component from any other sibling.

View classes and structures as independent contractors. They should be isolated and selfsufficient. Types collaborate through a published interface and hide extraneous details. Classes and structures should be fully abstracted. This avoids dependencies between components, which leads to error-prone and harder-to-maintain software.

Enumerations, also described in this chapter, represent a discrete set of constant values. The months of the year are ideal for enumeration. There are a discrete number of months: 12. Months can logically be assigned constant values from 1 to 12. Liberal use of enumerations can make code safer and more readable.