Use domain-specific types.
When working with business concepts, it is best to create customized types and objects that reflect the business domain.
For example, a social security number is not really a number. It’s a common rookie mistake to represent SSN with an integer; if you strip out the dashes and concatenate the digits, it looks like a number. But an integer does not have to be nine digits. An integer does not have leading zeroes for left padding. No, a social security number is a string of nine numeric digits. Because it has specific rules regarding what can and can’t be a legitimate SSN, it should be its own type. As an object, it can also have a toString method that puts the dashes back in.
Similarly, a ZIP code is likewise not an integer. The specification expects it to be a string of five numeric digits with zeroes left padded. Optionally, there may be a ZIP+4 extension. Don’t use an integer for this; create a custom type.
Type checking and other validations on the object can prevent errors. Using an object, you can control the format, the bounds, and the content. Within the program, other developers will have an easier time recognizing and working with domain type objects when they can see the rules listed in the object’s class. When people use primitive types, other developers are left to guess what the valid values could be.
Today's Card 