Finishing the System`s Outlines - Not Just a String
(Page 3 of 5 )
A more descriptive data type can represent many data types represented typically by a String. For example, although a name can be declared as a String, you could declare it as a
String . For example, although a name can be declared as a String , you could declare it as a A more descriptive data type can represent many data types represented typically by a String. For example, although a name can be declared as a String, you could declare it as a clumped data object:
class Name
{
String first_name;
String last_name;
String title; // e.g. Mr. Mrs.
String suffix; // e.g. Jr. III
};
To avoid the "everything is a String" syndrome, come up with a different type name to describe a variable that holds a set of characters that does not have any validation, formatting, or other meta-information associated with it. Suppose you decide on CommonString. Use that name in place of String to declare the data types of attributes, and reserve String as an implementation type. Then ask the question "Is that attribute really a CommonString?
Let us revisit the Address class. Using CommonString, we can describe the class as follows:
class Address
{
CommonString line1;
CommonString line2;
CommonString city;
CommonString state;
CommonString zipcode;
}
CommonStrings can contain any characters, just like an int can contain any integer values (within hardware limits). In Address, some fields are definitely not CommonStrings. A state is not a CommonString. Only certain values represent a valid state. For U.S. postal addresses, if we use abbreviations to represent the state, the abbreviation must appear on the U.S.
Postal Service's official list of abbreviations. So the state should be declared as a data type called State. This data type can provide an appropriate validation mechanism. That mechanism can check to see that a string is in the official list, or it can supply a set of strings of all official abbreviations for use in a drop-down display box.
A U.S. Zip Code is not just a CommonString either. You can describe it as a NumericString data type (e.g., one with all digits), as a FormattedString data type (one with five digits plus a dash plus four digits), or as a ZipCode data type. If any combination of digits was valid, using NumericString or FormattedString might be appropriate. However, declaring the attribute as a ZipCode type allows us to abstract away its actual representation.
Do not combine classes simply for implementation purposes. You can define both SocialSecurityNumbers and PhoneNumbers as strings of digits with two dashes. That does not make them equivalent--that is just accidental cohesion. They are two distinctly different classes with different validation. A phone number in the U.S. cannot begin with a 1 or a 0. Certain ranges of Social Security numbers are not used. These numbers can use the same type of formatted string for input or display purposes, but the semantics of each class are entirely different. You would never send a Social Security number to be dialed, nor would you attempt to record payroll taxes against a phone number. (All right, someone at some time will come up with a counterexample, so perhaps I should never say "never.")
Much data that might be a CommonString can be assigned its own data type. For example, filenames are usually typed as strings, but they cannot contain certain characters. In the Windows world, you cannot have any of the following characters in a filename: \,/,:,*,",?,<, >, or |. A FileName data type can represent a filename and enforce this limitation. An advantage of using a data type becomes apparent in graphical user interface (GUI) development. For instance, the user interface code could recognize the FileName data type and automatically insert a browse button next to a text field.
On the Web, parameter values for the Hypertext Transfer Protocol (HTTP) commands GET and PUT use encoded strings. Characters that are not alphabetic or numeric are encoded using their hexadecimal values. The encoded string is sent to the web server. Although the unencoded string and the encoded string are both implemented with strings, they are different. You can have invalid encoded strings--ones with unencoded punctuation, such as a hacker might send to a server. You could use an EncodedWebString class to represent strings on a server. If an input were not validated as an EncodedWebString, it would be rejected.
MOST STRINGS ARE MORE THAN JUST A STRING
Treat String as a primitive data type. Describe attributes with abstract data types, instead of as Strings.
Next: Constant Avoidance >>
More Practices Articles
More By O'Reilly Media
|
 This article is excerpted from Prefactoring, written by Ken Pugh (O'Reilly; ISBN: 596008740). Check it out today at your favorite bookstore. Buy this book now.
|
|
