In this post I want to make clear that using Strings as a datatype is terrible for design of objects. The development may be faster on the short run, but on the long run, a price has to be paid.
I’m working on a EJB 2.1/Struts project where a lot fields of objects are String. These fields are used to store different kinds of information: accountnumbers, phonenumbers, status information (an enumeration of values) etc.
The problem with using Strings as datatypes:
- operations on the strings are scattered all over the place. If you need a function to format a phonenumber, it often is created adhoc instead of in a suitable class. This makes logic very hard to find back and the consequence is that you get more code-duplication.
- it is easy to get inconsistent data: a phonenumber of 20 digits for example is not possible, but you can store anything in a String. This makes it very difficult to control the consistency of the data.
- you don’t have any typesafeness: you could pass a telephonenumber to a bankaccount format function. Using a specific datatype instead of a String, makes it possible to get compiletie typesafeness and this is a good way to decrease developmenttime.
- it is more difficult to understand what a field means (especially if the documentation is not that great): if you have a field of type String and name imsi, how can you tell it contains a phonenumber? If the field is of type Phonenumber, you know at least it is a phonenumber.
And I expect there are more, but these were the first that came to mind.
Ofcourse it is easier on the short run (you don’t have to create any special classes), but on the long run development will slowdown. I thought most developers knew this, but it appears that not all developers share the same knowledge.