OOP: Is it going to far to create a phone number object, or an address object?

Question

Many things can have phone numbers and addresses. . . people, places, etc. You want phone numbers and addresses to have the same functionality, format and validation whether it is a phone number or address for a person or a place etc.

Is it going to far to create a phone number class, and an address class, and use them in those objects that have phone numbers and addresses?

My question goes to other properties as well that could be reuseable across diverse objects.

Answer 1

Yes, you can go too far and this is borderline. I tend to draw the line at the point where it becomes cumbersome to treat things as more than a string, or another already defined class/type.

If you need to somehow manipulate phone numbers (by, for example, separating them into area code and other bits) or addresses (number, street, city, country and so forth) then, yes, consider making them objects.

I rarely do anything with phone numbers or addresses other than store and display them, in which case they're fine as strings without having to have their own dedicated class. For addresses, I don't even impose a separation based on parts (except maybe the zipcode), preferring free-format entry so as to not annoy those with addresses of a format I don't know about.

Going the reductio ad absurdum route, you could also objectify the characters that make up your phone number but that would be silly.