试图避免类结构中的多个子类型

Question

I have two abstract classes Business & Person. The problem is that I have a customer type that can be either a Business or a Person. Is there a way to model this so that I don't have both CustomerBusiness and CustomerPerson classes? Multiple inheritance isn't an option as this is C#. I've been looking at this so long I can't see the forest for the trees.

public abstract class Business {
  public string Name { get; set; }
}

public abstract class Person {
  public string FirstName { get; set; }
  public string LastName { get; set; }
  public string MiddleName { get; set; }
  public DateTime? BirthDate { get; set; }
  public string Comments { get; set; }
}

public class CustomerBusiness : Business, CustomerRoles {
  public bool BillTo { get; set; }
  public bool ShipTo { get; set; }
  public bool DeliverTo { get; set; }
  public EntityType Type { get; set; }
}

public class CustomerPerson : Person, CustomerRoles {
  public bool BillTo { get; set; }
  public bool ShipTo { get; set; }
  public bool DeliverTo { get; set; }
  public EntityType Type { get; set; }
} 

public interface CustomerRoles {
  bool BillTo { get; set; }
  bool ShipTo { get; set; }
  bool DeliverTo { get; set; }
}

Answer 1

You could prefer composition over inheritance having the Business and Person classes "have a" ICustomerRoles instead of "is a" ICustomerRoles .

public class Business
{
    public string Name { get; set; }

    public ICustomerRoles CustomerRoles { get; set; }
}

public class Person
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public string MiddleName { get; set; }
    public DateTime? BirthDate { get; set; }
    public string Comments { get; set; }

    public ICustomerRoles CustomerRoles { get; set; }
}

Answer 2

I would say that you have your heirarchy in the wrong order. Customer should be a base class and then Business and Person should be implementations of the Customer class. I'm sure there are more attributes of a Customer that are common to all types of Customer other than those in the CustomerRoles interface.

I would have thought there would be things like CustomerCode etc. Also you could state that all customers have a Name property, and it's up to the getter in each sub class to return the appropriate value. As in a Business would have a single property called Name, whereas a person would have each of FirstName, MiddleName, Surname and also a Name property that would concatenate these in some way.