我是面向对象编程的新手,我正在学习这些概念。现在我只需要逻辑组织课程就需要帮助。关于方法,属性和构造函数的部分我可以搞清楚。我被分配了以下这个问题。
Holiday Travel Vehicles出售新的休闲车和旅行 拖车。当新车到达Holiday Travel Vehicles时,一辆新车 车辆记录已创建。新车记录中包括一个 车辆序列号,名称,型号,年份,制造商和基本成本。 当客户到达Holiday Travel Vehicles时,他或她的工作 与销售人员谈判购车。购买时 已经商定,销售发票由销售人员完成。 发票总结了购买,包括完整的客户 信息,有关交易工具的信息(如果有的话), 折价补贴和购买车辆的信息。如果 客户要求经销商 - 安装选项,它们列在 发票也是。发票还总结了协商价格, 加上任何适用的税费和许可费。交易结束 在销售发票上有客户签名。
到目前为止,我所想做的是制作一个带有客户和车辆子类的发票超类,因为车辆信息和客户信息在发票上。然而,由于车辆在到达经销商时获得了记录,我还考虑过将车辆作为自己的类别与子类旅行拖车和RV,因为一个涉及发动机而一个没有。但是,如果我在发票中记录车辆记录和车辆信息,我就无法将车辆作为自己的车级和发票的子类。(如果我所说的一切都没有意义,我很抱歉我真的很困惑。)那我该如何安排这些课程呢?我真的迷路了。
答案 0 :(得分:2)
Holiday Travel Vehicles销售新的休闲车和旅行拖车。当新车到达Holiday Travel Vehicles时,会创建一个新的车辆记录。新车辆记录中包括车辆序列号,名称,型号,年份,制造商和基本成本。 当客户到达Holiday Travel Vehicles时,他或她与销售人员一起协商购买车辆。在同意购买时,销售人员完成销售发票。发票总结了购买,包括完整的客户信息,以旧换新车辆的信息(如果有的话),以旧换新限额以及购买车辆的信息。如果客户要求经销商安装选项,它们也将列在发票上。发票还总结了最终协商价格,以及任何适用的税费和许可费。交易以销售发票上的客户签名结束。
确定此方案中描述的数据实体(您应该找到六个)。 客户在首次购买Holiday Travel Vehicles时会获得一个客户ID。为客户记录姓名,地址和电话号码。以旧编号,品牌,型号和年份描述以旧换新的车辆。经销商安装的选项由选项代码,描述和价格描述。
为每个实体开发属性列表。 每张发票只列出一个客户。一个人在购买车辆之前不会成为客户。随着时间的推移,客户可以从Holiday Travel Vehicles购买许多车辆。每张发票必须由一名销售人员填写。新的销售人员可能没有出售任何车辆,但经验丰富的销售人员可能已售出许多车辆。每张发票仅列出一辆新车。如果库存中的新车尚未售出,则不会有发票。一旦车辆售出,将只有一张发票。客户可能决定不向车辆添加任何选项,或者可以选择添加许多选项。选项可以列在没有发票上,也可以列在许多发票上。购买新车时,客户可以交易不超过一辆车。以旧换新的车辆可能会出售给另一位客户,后来他们将另一位客户用另一辆假日旅行车进行交易。
根据Holiday Travel Vehicles生效的这些商业规则,绘制ERD并记录与适当的基数和形态的关系
答案 1 :(得分:1)
使车辆和客户成为发票的子类并不是很有意义。我认为您想要的是制作车辆类和客户类,然后在发票类中,您可以保存车辆对象的实例和它所指示的客户对象。
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
是一种车辆),或者points
是某种东西(发票上有车辆参考)。我希望这很清楚,这是我记得在我第一次学习它的过程中遇到的困难。
答案 2 :(得分:0)
我可以给你一个提示,当你注意到一些元素共享功能时总是使用继承,虽然只共享一个功能,但使用继承。现在你只能看到一个共同特征,但也许有一天你会发现它们共享不止一个。
我可以说的另一个重要的事情是你不应该建立一个不相关的元素的层次结构,例如,你不应该建立一个超类车辆和两个子类汽车和马,也许你认为他们分享一些功能但它们不在同一类别的元素中,在这种情况下,研究更多的层次结构更好。
与继承相关的另一个重要因素是多态和动态绑定的概念,非常有用。
希望它对你有用,