我是面向对象编程的新手，我正在学习这些概念。现在我只需要在合理组织课程方面得到帮助。关于方法、属性和构造函数的部分我可以弄清楚。我被分配了以下问题。
假日旅行车销售新型休闲车和旅行拖车。当新车到达假日旅行车时创建车辆记录。新车记录中包括车辆序列号、名称、型号、年份、制造商和基本成本。当客户到达假日旅行车时，他或她工作与销售人员协商购买车辆。当购买已经达成一致，销售发票由销售人员填写。发票汇总了购买情况，包括完整的客户信息，以旧换新车辆信息（如有）以旧换新津贴，以及购买车辆的信息。如果客户要求经销商安装选项，这些选项列在发票。发票还总结了协商价格，加上任何适用的税费和许可费。交易结束销售发票上有客户签名。
到目前为止，我想做的是制作一个带有客户和车辆子类的发票超类，因为车辆信息和客户信息都在发票上。然而，由于车辆在到达经销商处时会得到记录，我也考虑将车辆作为自己的类别，包括旅行拖车和RV，因为其中一个涉及发动机，而另一个不涉及发动机。然而，如果我在发票中做车辆记录和车辆信息，我不能使车辆既是自己的类，也是发票的子类。（如果我所说的一切都没有意义，我很抱歉，我只是真的很困惑。）那么我应该如何安排这些课程呢？我真的很失落。
假日旅行车销售新型休闲车和旅行拖车。当新车到达假日旅行车辆时，将创建一个新的车辆记录。新车记录中包括车辆序列号、名称、型号、年份、制造商和基本成本。当客户到达假日旅行车时，他或她会与销售人员协商车辆购买事宜。当同意购买时，销售人员会填写销售发票。发票汇总了购买情况，包括完整的客户信息、以旧换新车辆的信息（如有）、以旧换货津贴以及所购买车辆的信息。如果客户要求经销商安装选件，它们也会列在发票上。发票还汇总了最终协商价格，以及任何适用的税费和许可费。交易以客户在销售发票上的签名结束。
-
识别此场景中描述的数据实体（您应该找到六个）。当客户第一次从假日旅行车购买时，他们会被分配一个客户ID。记录客户的姓名、地址和电话号码。以旧换新车辆由序列号、品牌、型号和年份描述。经销商安装的选装件由选装件代码、说明和价格进行说明。
-
为每个实体制定一个属性列表。每张发票只列出一位客户。一个人在购买车辆之前不会成为客户。随着时间的推移，客户可能会从假日旅行车购买许多车辆。每张发票只能由一名销售人员填写。一个新的销售人员可能没有销售过任何车辆，但经验丰富的销售人员很可能已经销售过许多车辆。每张发票只列出一辆新车。如果库存中的新车尚未售出，则不会有发票。一旦车辆售出，则只有一张发票。客户可能会决定不向车辆添加任何选项，也可能会选择添加许多选项。一个选项可能在没有发票的情况下列出，也可能在许多发票上列出。客户在购买新车时最多可以换一辆车。以旧换新的车辆可能会卖给另一位客户，后者随后会将其换成另一辆假日旅行车。
-
根据假日旅行车的这些业务规则，绘制ERD并记录与适当基数和模式的关系
将车辆和客户作为发票的子类并没有多大意义。我认为您想要的是创建一个车辆类和一个客户类，然后在您的发票类中，您可以持有车辆对象及其指定的客户对象的实例。
public class Invoice {
private Vehicle MyVehicle;
private Customer MyCustomer;
//...etc
}
public class Customer {
private String FirstName;
//...etc
}
public class Vehicle{
private String Model;
//...etc
}
对于旅行拖车和RV级别，细分车辆更有意义，因为它们本质上是一种车辆，因此将与车辆共享许多共同变量。你需要问自己的问题是，is是其他东西（RV is是车辆），还是points是什么东西（发票上提到了车辆）。我希望这一点很清楚，这绝对是我第一次学习时遇到的困难。
我可以给你一个提示，当你注意到一些元素共享特性时，总是使用继承，尽管只共享一个特性，但使用继承。现在你只能看到一个共同的功能，但也许有一天你会注意到它们共享了不止一个。
我可以说的另一件重要的事情是，你不应该建立一个没有关系的元素层次，例如，你不可以建立一个超类车辆和两个子类汽车和马，也许你认为它们有一些共同的功能，但它们不在同一类元素中，在这种情况下，更深入地研究层次结构更好。
与继承相关的另一件重要的事情是多态性和动态绑定的概念，这非常有用。
希望它能对你有用，