哪种 class 结构最适合设置？
Which class structure would be most suitable for the set up?
我正在为面向对象的设计模块完成大学作业。在对名词和动词进行语言分析以及用例识别之后，现在正在制作 class 图。
程序相关部分如下：
该程序供商店员工使用。有一个产品列表代表商店中的商品。每个产品都有独特的详细信息，包括关联的供应商和送货公司（可以有父级 class 称为 'external company'）。
还应该有跟踪订单（但不是下单）的功能。这些要求不包括每个产品的多个订单；每种产品一次只能补货一次。
这让我想到与产品订单相关的任何详细信息都可以列为该产品对象的属性，而不是链接到产品对象的订单对象的属性。如果每个产品有多个订单，我肯定会在产品列表之外制作一个订单列表，但每个产品只有 1 个。
问题在于拥有所有产品属性（名称、重量、保质期、ID、单位成本、销售速度、照片等）和所有订单属性（预计订购日期、订购金额、交货日期、欠供应商的金额、最后订单的日期），因为产品的属性会使产品 class 变得笨重。或者，将它们分成两个 classes 可能会产生冗余。此外，大多数订单'attributes'实际上是使用产品属性执行计算的结果，而不是'base attributes'（为不正确的术语道歉）。
class图表的选项如下所示。请原谅我缺乏细节，因为这只是一个模型，用于可视化上述问题中的内容。
选项 1：
选项 2：
任何关于 class 图到 select 的帮助（如果有）将不胜感激，阅读问题时可能想到的任何其他信息也将不胜感激。
成功的 OO 设计的关键是 separation of concerns。这意味着，如果您知道产品固有的东西和与该产品的订单相关的其他东西，您应该将它们分开。
现在，经过 20 年的 ERP，我可以告诉你，一次一个订单只是暂时的情况。迟早，你将不得不进化，所以如果它如此明显，那么最好预测一下。所以 选项 2 是可行的方法。
现在您应该在图表中做几件事：
- 首先，添加multiplicity。
- 只有当你真的想表达单向时才使用箭头navigability。在你的情况下，我强烈反对它。
- 您对
Product、Order、Supplier 和 External Company 的联想与您的叙述不符。您说每个产品都有关联的供应商和送货公司。所以它们之间应该有一个直接的link。您还说过，供应商可以将外部公司作为母公司。所以可能会有没有任何外部母公司的订单。
- 当然是隐含的，但是一个订单也会有一个公司。即使在给定时间只有一个，如果您将其保存在数据库中，您也应该能够可靠地找到任何给定供应商的订单，甚至是以前的供应商。
- 请毫不犹豫地 label the associations 为您的图表添加表现力。因为有些联想看似多余，但从意义上看根本不是。
最后一件事：我不知道您的任务，但我建议您专注于域 类 并释放 GUI。为什么 ？因为一旦您开始使用 GUI，您肯定会有 GUI sub类 与产品列表以外的其他事物相关联。事实上，我发现它具有误导性。
我正在为面向对象的设计模块完成大学作业。在对名词和动词进行语言分析以及用例识别之后，现在正在制作 class 图。
程序相关部分如下：
该程序供商店员工使用。有一个产品列表代表商店中的商品。每个产品都有独特的详细信息，包括关联的供应商和送货公司（可以有父级 class 称为 'external company'）。
还应该有跟踪订单（但不是下单）的功能。这些要求不包括每个产品的多个订单；每种产品一次只能补货一次。
这让我想到与产品订单相关的任何详细信息都可以列为该产品对象的属性，而不是链接到产品对象的订单对象的属性。如果每个产品有多个订单，我肯定会在产品列表之外制作一个订单列表，但每个产品只有 1 个。
问题在于拥有所有产品属性（名称、重量、保质期、ID、单位成本、销售速度、照片等）和所有订单属性（预计订购日期、订购金额、交货日期、欠供应商的金额、最后订单的日期），因为产品的属性会使产品 class 变得笨重。或者，将它们分成两个 classes 可能会产生冗余。此外，大多数订单'attributes'实际上是使用产品属性执行计算的结果，而不是'base attributes'（为不正确的术语道歉）。
class图表的选项如下所示。请原谅我缺乏细节，因为这只是一个模型，用于可视化上述问题中的内容。
选项 1：
选项 2：
任何关于 class 图到 select 的帮助（如果有）将不胜感激，阅读问题时可能想到的任何其他信息也将不胜感激。
成功的 OO 设计的关键是 separation of concerns。这意味着，如果您知道产品固有的东西和与该产品的订单相关的其他东西，您应该将它们分开。
现在，经过 20 年的 ERP，我可以告诉你，一次一个订单只是暂时的情况。迟早，你将不得不进化，所以如果它如此明显，那么最好预测一下。所以 选项 2 是可行的方法。
现在您应该在图表中做几件事：
- 首先，添加multiplicity。
- 只有当你真的想表达单向时才使用箭头navigability。在你的情况下，我强烈反对它。
- 您对
Product、Order、Supplier和External Company的联想与您的叙述不符。您说每个产品都有关联的供应商和送货公司。所以它们之间应该有一个直接的link。您还说过，供应商可以将外部公司作为母公司。所以可能会有没有任何外部母公司的订单。 - 当然是隐含的，但是一个订单也会有一个公司。即使在给定时间只有一个，如果您将其保存在数据库中，您也应该能够可靠地找到任何给定供应商的订单，甚至是以前的供应商。
- 请毫不犹豫地 label the associations 为您的图表添加表现力。因为有些联想看似多余，但从意义上看根本不是。
最后一件事：我不知道您的任务，但我建议您专注于域 类 并释放 GUI。为什么 ？因为一旦您开始使用 GUI，您肯定会有 GUI sub类 与产品列表以外的其他事物相关联。事实上，我发现它具有误导性。