It sounds like what you are trying to model are phone contacts and email contacts, but I think what you really have are contacts with a primary contact method: phone or email. The way I would structure it would be with composition -- assuming that you want the flexibility to have multiple phone numbers/emails. If you can live with a single one of each, you could store it directly in the contacts table. If you need multiple addresses, then handle it the same way as phone/email with a separate table.
Contacts Table
ContactID
FirstName
LastName
MI
StreetAddress1
StreetAddress2
City
StateProvince
PostalCode
PreferredContactMethod (0 = Phone, 1 = Email)
... more details ...
PhoneNumbers Table
PhoneID
ContactID
PhoneNumber
IsPrimary
...more details...
EmailAddresses Table
EmailID
ContactID
EmailAddress
IsPrimary
...more details...
For your classes then, you would have a Contact class, which contains one or more PhoneNumbers and one or more EmailAddresses. If you had other things than Contacts that had phone numbers or email addresses, then it might make sense to have interfaces indicating that they are IPhoneable or IEmailable -- meaning just that you could add/remove phone numbers or email addresses from them, like so:
public interface IPhoneable
{
public PhoneNumber GetPrimaryNumber();
public void AddNumber( PhoneNUmber number );
public IEnumerable<PhoneNumber> GetNumbers();
}
public interface IEmailable
{
public EmailAddress GetPrimaryAddress();
public void AddEmailAddress( EmailAddress address );
public IEnumerable<EmailAddress> GetEmailAddresses();
}
public class Contact : IPhoneable, IEmailable
{
private List<PhoneNumber> phoneNumbers;
private List<EmailAddresses> emailAddresses;
public int ContactID { get; private set; }
public string FirstName { get; set; }
...
public Contact()
{
this.phoneNumbers = new List<PhoneNumber>();
this.emailAddresses = new List<EmailAddress>();
}
public PhoneNumber GetPrimaryNumber()
{
foreach (PhoneNumber number in this.phoneNumbers)
{
if (number.IsPrimary)
{
return number;
}
}
return null;
}
...
}
If you wanted, you could have a PhoneableContact and an EmailableContact that would subclassed off Contact and be differentiable based on the preferred contact method, but I don't really see a need for this. If you did that, then Contact wouldn't implement either interface -- the subclasses would implement the appropriate ones respectively.