More or Less Types

One debate that seems to arise in many of the projects I work on is at what level to create types?  For instance if you have a Customer object does the Customer object look like this?

    public class Customer
    {
        public string CompanyName
        { get; set; }

        public string FirstName
        { get; set; }

        public string LastName
        { get; set; }

        public string Address1
        { get; set; }

        public string Address2
        { get; set; }
        
        public string City
        { get; set; }

        public string State
        { get; set; }

        public string City
        { get; set; }

        public string ZipCode
        { get; set; }

        public string BusinessPhone
        { get; set; }

        public string HomePhone
        { get; set; }

        public string CellPhone
        { get; set; }
   }

or like this?

   public class Customer
    {
        public string CompanyName
        { get; set; }

        public Name CustomerName
        { get; set; }
        
        public Address BusinessAdress
        { get; set; }
        
        public Phone BusinessPhone
        { get; set; }

        public Phone HomePhone
        { get; set; }

        public Phone CellPhone
        { get; set; }
   }

I am a fan of having more types then less. The second Customer implementation lets me think in terms of Name, Address and Phone objects and will guide developers to have the same structure for these objects throughout the system. Without these smaller types you can have addresses with no Address2 field in some places but not others, Names with middle initials on some classes, but not others. This is all fine until these objects need to share data, and their data doesn’t conform.

I suppose the downside is you have more class files to maintain, which really isn’t a downside at all. To use the smaller objects you have to conform to their rules, which is only a downside if the system doesn’t have any consistent rules. If this is the case I’d wonder about the system design. Some would argue you should never have any primitive types on your business objects, that everything should be it’s own class. This would nicely abstract and encapsulate, but is it overkill?

At some point a class has to have primitives. In our Customer class the Address object will be made up of string properties, should we create types for Address1, Address2. etc….? Some would argue you should, but at some point the data will be stored in a primitive. So the real question in my mind is where to stop typafying everything. What I tend to advise is to have top level business objects that rarely have primitives, but allow their support objects to be made up of them. This seems to force system wide structure on support objects, without getting into objectifying everything overkill, at least in my mind. I’d be open to using more types, but would be uncomfortable with a less type driven approach.

Another plus to a more type driven approach is you can make use of operator overloads. This allows casting of one type to another, with the adaption logic implemented in the casting operator. For instance, you can cast a string to a Phone type, and the validation logic can be implemented in the casting operator. Consumers can then easily set a string to a phone variable.