When to use basic types (Integer, String), and when to write a new class?

Question

Stackoverflow users: A lot of things can be represented in programs by using the basic types, or we can create a new class for it.

Example: A social security number can be a number, string or its own object.

(Other common examples: Phone numbers, names, zip codes, user id, order id and other id's.)

My question is: When should the basic types be used, and when should we write ourselves a new class?

I see that when you need to add behavior, you'll want to create a class (example, social security number parsing, validation, formatting, etc). But is this the only criteria?

I have come across cases where many of these things are represented as java Integers and/or Strings. We loose the benefit of type-checking, and I have often seen bugs caused by parameters being mixed in calls to function(Intever, Integer, Integer, Integer).

Couldn't we benefit from having function(OrderId, ExternalOrderId, UserId, SalesManId) isntead and benefit from type checking, even though none of these alone justifies having its own class?

Obviously, the answer is "it depends". But, what do you think, and what do you normally do?

Answer 1

If multiple common properties exist for that real life object, and you want to have detailed methods for manipulating these properties, use a class. If there is only one type of data, and there is no need for advanced manipulation, use a primitive.

Answer 2

The question to ask isn't "How can I store this data?", but rather "How can I act on this data?".

To use a few of your examples: An SSN is numeric, in the form of XXX-XX-XXXX. If you're going to perhaps read a user-input value for this, then you need to provide some kind of validation to make sure the format has been input properly. You might also want to provide a method to input the 3 numbers individually (such as 3 text boxes on a form), but concatenate them internally into the SSN. Using a String class or Integer alone wouldn't provide the means of performing these tasks, so it's a good idea to give it it's own type, and make sure only valid values can ever be stored. The type would have an Int or String internally to actually hold the data, but the encapsulating class ensures that you read/write the value in a valid way.

Phone Numbers, Zip codes are other areas where you might want some validation, so it's sensible to use them there.

UserIds would depend on the scenario, but a primitive type would usually be sufficient. If you needed to constrain user ids into a certain numeric range though (different from the range of any primitive Integer type), you could encapsulate that into a class.

Answer 3

As long as the built in types makes sense for what you are using them for, there is no reason to make a special class. When it is unclear what the data in a variable actually means, you can create a class to make it clear.

A value like a phone number for example works well as a string. It's numerical in nature, however you won't be doing any calculations on it, so any validation you do on it is not critical for the function, it's merely to keep users from entering nonsense.

A value like a distance is a candidate for a class. You could use an integer or a double to store a distance, but then you have to add some more information to make the value make sense, for example naming the variable DistanceInMeters. You could create a class for the distance to limit it's use, only supplying a FromMeters method as constructor, and only the property Meters for reading the value. That way it's clear what the value means.

Answer 4

It's a trade-off. Basic types are easy to understand while custom types should be understood first. It should be one of the main entities of your project domain to be declared as a custom type.

a criteria is: if it worth a custom type, there's already a domain-specific equivalent term for it. For example we call "the man who drives a car" a "driver" in transport domain while there are passengers and ... while in medical domain all drivers and passengers are human and the criteria would be something else.

Answer 5

If that field always used in combination with other fields, making a logical grouping makes sense. This can be seen when there methods that consistently take the same set of parameters.

Grouping fields into logical units will abstract the logical unit itself from the users of the logical unit. This means implementation detail is hidden, enabling changes to the underlying representation of the data without affecting other areas of the code.

If there is functionality that solely acts upon that field, then I consider it a candidate to be a class. Also, if the unit is simple but is always used in the same way, I consider making it into a class and putting that functionality into the class. This means the functionality is only maintained in one place, so making a change to that behaviour is easier, and your code will contain less repetition.