Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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 bob@email.com; 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 "bob@email.com" 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.)

share|improve this question

closed as not constructive by Ryathal, Matthieu, Jim G., Mark Trapp, gnat Sep 14 '12 at 11:01

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

    
ContactInformation is my best guess. –  Robert Harvey Jun 28 '12 at 17:19

1 Answer 1

up vote 3 down vote accepted

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

share|improve this answer
    
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 '12 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 '12 at 20:20

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