In creating a description of a use case or a model of a possible class, avoid using primitive data types. Pretend that ints or doubles do not exist. Almost every type of number can be described with an abstract data type (ADT). Items are priced in Dollars (or CurrencyUnits, if you are globally oriented). The number of physical copies of an item in an inventory is a Count. The discount that a good customer receives is denoted with a Percentage. The size of a CDDisc is expressed as a Length (or LengthInMeters or LengthInInches if you are going to be sending a satellite into space). The time for a single song on a CDRelease could be stored in a TimePeriod.

Using an ADT places the focus on what can be done with the type, not on how the type is represented. An ADT shows what you intend to do with the variable. You can declare the variable as a primitive data type and name the variable to reflect that intent. However, a variable declared as an abstract data type can have built-in validation, whereas a variable declared as a primitive cannot.

Each ADT needs a related description. For example, a Count represents a number of items. A Count can be zero or positive. If a Count is negative, it represents an invalid count. Declaring a variable as a Count conveys this information. You can create variations of Count. You may have a CountWithLimit data type with a maximum count that, if exceeded, would signal an error.

You can place limits on many different data types. For example, Ages (of humans) can range between 0 and 150 years, SpeedLimits (for automobiles) between 5 and 80 mph, and Elevations (for normal flying) between 0 and 60,000 feet.* All these types can be represented by an int or a double, but that is an implementation issue, not an abstraction issue.

Abstract types can contain more than just validation. A price can be represented in Dollars. The string representation of a Dollar differs from the string representation of a double. A string for Dollar has at least a currency symbol and perhaps some thousands separators (e.g., commas). Multiplying a Dollar by a number can result in a Dollar with cents, but not fractions of a cent. Here is a possible Dollar class:

  class Dollar
      {
      Dollar multiply_with_rounding(double multiplier);
      Dollar add(Dollar another_dollar);
      Dollar subtract(Dollar another_dollar);
      String to_string(); //
      };

If your language provides the ability to define operators for a class (such as + and -), you can use arithmetic symbols for the corresponding operations. You can also use the appropriate method name to have a Dollar be converted automatically to a String if it appears in an appropriate context. How you represent the abstract data type that you use for a value is an implementation detail. You can make up a class for each type. If you work with C++, you can make up typedefs for each simple type for which there is no additional functionality. For other languages, you can convert some simple types into primitive types. In that case, you might want to use variable names that include the type (e.g., double price_in_dollars).

WHEN YOU'RE ABSTRACT, BE ABSTRACT ALL THE WAY

Do not describe data items using primitive data types.

This guideline suggests using explicit typing in describing the problem and the solution. By using abstract data types in the beginning, you are, in effect, more abstract. If you explicitly type all your attributes and parameters, you can always switch to implicit typing if the explicit typing gets in the way. It is much harder to go in reverse.

ADTS AND SPEED OF DEVELOPMENT

I was the chief judge of the Droege Developer Competition. In this event, pairs of developers competed to code a project for a nonprofit organization in one day. They were provided specifications and the results were judged the next day. Developers who used a product from Magic Software (http:// www.magicsoftware.com/) consistently scored high and often won the competition. That product includes the ability to define data types that contain validation rules, display rules (e.g., drop-down lists or radio buttons), and formatting rules. The record layout in the tables is defined using these data types, rather than primitive Structured Query Language (SQL) types. To display a record, the record fields were placed onto the display window. The requisite formatting and validation for each field were already coded. Additional validation could be added when necessary.

The data typing feature, which is a particular implementation of abstract data typing, was key in the ability to create a working system quickly.