对于如何以面向对象的方式组织这个组织(包括尝试)，几乎没有什么损失。

Question

我对面向对象编程有点陌生，我正在学习这些概念。现在，我只需要在逻辑上组织类的帮助。有关方法、属性和构造函数的部分我可以理解。我被分配了以下问题。

假日旅行车辆出售新的娱乐车辆和旅行拖车。当新车辆到达假日旅游车辆时，就创造了新的车辆记录。新车辆记录中包括车辆序列号、名称、型号、年份、制造商和基本成本。当顾客到达假日旅游车辆时，他或她会与销售人员协商购买车辆。当达成购买协议时，销售人员将填写销售发票。发票概述了购买情况，包括完整的客户信息、交易车辆信息(如果有的话)、交易补贴以及购买车辆的信息。如果客户要求经销商安装的选项，它们也被列在发票上。发票还概述了谈判价格，以及任何适用的税收和许可费。交易结束时，销售发票上有客户签名。

到目前为止，我想做的是制作一个带有客户和车辆子类的发票超类，因为车辆信息和客户信息都在发票上。然而，由于车辆在到达经销商时获得记录，我也考虑让汽车与子类旅行拖车和房车同级，因为其中一个涉及发动机，而另一个则不涉及。但是，如果我在发票中做车辆记录和车辆信息，我不能使车辆既属于自己的类别，又是发票的子类。(如果我所说的一切都没有意义，对不起，我真的很困惑。)那我该怎么安排这些课呢？我真的迷路了。

Answer 1

让车辆和客户成为发票的子类并不是很有意义。我认为您想要的是创建一个vehicle类和一个customer类，然后在您的发票类中，您可以保存vehicle对象和它指定的customer对象的一个实例。

public class Invoice {
    private Vehicle MyVehicle;
    private Customer MyCustomer;
    //...etc
}

public class Customer {
    private String FirstName;
    //...etc
}

public class Vehicle{
    private String Model;
    //...etc
}

对于旅行拖车和房车类，它更有意义的子类车辆，因为他们在本质上是一个车辆，因此将共享许多共同的变量与车辆。您需要问自己的问题是，某物是is ( RV is a vehicle)，还是points (发票中有车辆的引用)。我希望这是明确的，这肯定是我记得在我第一次学习的时候所经历的挣扎。

Answer 2

假日旅行车辆出售新的娱乐车辆和旅行拖车。当新车辆到达假日旅游车辆时，就创造了新的车辆记录。新车辆记录中包括车辆序列号、名称、型号、年份、制造商和基本成本。当顾客到达假日旅游车辆时，他或她会与销售人员协商购买车辆。如已同意购买，销售人员将填写销售发票。发票总结采购，包括完整的客户信息，交易车辆(如果有的话)的信息，交易补贴，以及购买车辆的信息。如果客户要求经销商安装的选项，它们也将被列在发票上。发票还总结了最后协商的价格，以及任何适用的税收和许可费。交易结束时，销售发票上有客户签名。

1. 标识此场景中描述的数据实体(您应该找到6个)。当顾客第一次从假日旅行车辆购买时，他们会被分配一个客户身份证。为客户记录姓名、地址和电话号码。交易车辆由序列号、制造、型号和年份来描述.交易商已安装的选项由期权代码、说明和价格描述。
2. 为每个实体开发一个属性列表。每张发票只列出一位顾客。一个人在购买一辆汽车之前不会成为顾客。随着时间的推移，客户可以从假日旅游车辆购买一些车辆。每张发票必须只由一名销售人员填写。一个新的销售人员可能没有出售任何车辆，但经验丰富的销售人员可能已经出售了许多车辆。每张发票只列出一辆新车。如果库存中的新车辆尚未售出，将没有发票。一旦汽车销售，将只有一张发票。客户可以决定在车辆上不添加任何选项，也可以选择添加多个选项。一个选项可以列在没有发票上，也可以列在许多发票上。顾客在购买一辆新车时，可换一辆以上的车。这种换乘车可能会卖给另一位客户，后者随后会在另一辆假日旅游汽车上进行交易。
3. 根据这些在假日旅行车辆上生效的业务规则，绘制ERD，并记录与适当基数和方式的关系。

Answer 3

我可以给您一个提示，当您注意到一些元素共享特性时，总是使用继承，虽然只有一个特性，但使用继承。现在您只能看到一个共同的特性，但也许有一天您会注意到它们有多个共同之处。

我能说的另一件重要的事情是，你不应该构建一个不相关的元素的层次结构，例如，你不应该构建一个超类车辆和两个子类--汽车和马，也许你认为它们有一些共同的特性，但它们并不属于相同的元素类别，在这种情况下，一个研究更深入的层次更好。

与继承有关的另一个重要的概念是多态和动态绑定，非常有用。

希望这对你有用，