2

I am in the middle of refactoring code and would like to get some ideas on variable naming so that my new names clearly represent the data they hold.

I have a class called ContactMethod which makes sense to me; each instance is a different way to contact someone. My problem comes when naming the properties of ContactMethod. For example, one instance might be a Fax number of 555-555-5555 while another could be an Email address of [email protected]; I've got a property called contactMethodType to hold the values "fax" or "email", but I don't know what to call the "555-555-5555" or "[email protected]" part. Has anyone here created a good generic name for this piece of contact information?

(PS - the old convention was to call it a "Phone" with fields "phoneType" holding the "fax"/"email" value and "phoneId" holding the number/address. Yuck.)

Improve this question
1
  • ContactInformation is my best guess.
    – Robert Harvey
    Jun 28, 2012 at 17:19

1 Answer 1

Reset to default
3

To my mind, if you can't think of a meaningful name for an abstraction, it means that the abstraction is probably not going to help you. Out of curiousity why does calling it ContactMethod help you or make more sense than a separate Phone and Email class?

Abstractions are supposed to provide you with common behaviour for entities which are similar. I don't know anything about the particular problem which you're trying to solve, but off the top of my head I can't really see much in common between a phone number and an e-mail address. For example, your validation will probably follow totally different rules, and the way in which you use an e-mail address to contact someone (sending them an e-mail) is different to the way you'd contact them with their phone number.
(Also, the fact that you are storing a separate ContactType suggests your code may be packed full of if(type == phone) else if(type == email) etc anyway).

IMO it is ok (and sometimes better/desirable) to create separate data/entities for things which are logically different. Sometimes you can try too hard to find a common one-size-fits all solution which ultimately doesn't make your life any easier

Improve this answer
2
  • To answer your first question, the main reason that we grouped them under ContactMethod was because they both existed in the same database. Our DBAs are...quite resistant to changing the schema, so I guess I'm just trying to fit round pegs in square holes.
    – RustyTheBoyRobot
    Jun 28, 2012 at 20:16
  • "I can't really see much in common between a phone number and an e-mail address" Our system allows users to setup automatic notifications via different contact methods. That's really the common concept between the two, but I agree that they would benefit more from an inheritance approach where Phone and Email are children of ContactMethod rather than different instances of the same class
    – RustyTheBoyRobot
    Jun 28, 2012 at 20:20

Not the answer you're looking for? Browse other questions tagged or ask your own question.