哪种班级结构最适合设置？ [英] Which class structure would be most suitable for the set up?

问题描述

我正在为面向对象的设计模块进行大学作业。在对名词和动词进行语言分析并确定用例之后，现在在制作类图。

I am working on a university assignment for a Object Oriented design module. Following linguistic analysis of nouns and verbs, and identification of use cases, the class diagram is now being made.

该程序的相关部分如下：

The relevant parts of the program are as follows:

• 该程序供商店员工使用。这里有代表商店里商品的产品清单。每个产品都有唯一的详细信息，包括相关的供应商和送货公司（可以将其父类称为外部公司）。

• The program is used by shop employees. There is a list of products that represent what is in the shop. Each product has unique details, including associated supplier and delivery company (which can have parent class called 'external company').

还应该具有跟踪订单的功能（但不能下订单）。要求不包括每种产品的多个订单；每个产品一次只能一次补货。

There should also be functionality to track orders (but not place). The requirements do not include multiple orders per product; only a single re-stock at a time per product.

这使我认为与产品订单相关的任何详细信息都可以作为该产品的属性列出对象，而不是链接到产品对象的订单对象的属性。如果每个产品有多个订单，我肯定会在产品列表之外再创建一个订单列表，但是每个产品只有一个。

This leads me to think that any details associated with the order for a product can be listed as attributes for that product object, as opposed to being attributes of an order object that is linked to the product object. If there was multiple orders per product I would definitely make an order list in addition to a product list however there is just 1 per product.

问题在于具有所有产品属性（名称，重量，保质期，ID，单位成本，销售速度，照片等）和所有订单属性（估计日期）订单，订单金额，交货日期，欠供应商的金额，最后订单日期），因为产品的属性会使产品类别​​繁琐。或者，将它们分为两类可能会产生冗余。此外，大多数订单属性实际上是使用产品属性而不是基本属性（对不正确的术语表示歉意）执行的计算结果。

The issue is that having all product attributes (name, weight, shelf life, ID, cost per unit, sales velocity, photo etc) and all order attributes (estimated date to order, amount to order, delivery date, amount owed to supplier, date of last order), as attributes of the product would make the product class cumbersome. Alternatively, separating them into two classes may create redundancy. Furthermore, most of the order 'attributes' are actually results of calculations performed using product attributes, not 'base attributes' (apologies for incorrect terminology).

类别的选项图如下所示。请原谅我缺乏细节，因为这只是一个可视化上面问题中的内容的模型。

The options for class diagram are shown below. please forgive me for lack of detail as this is just a mock up to visualise what is in the question above.

选项1：

选项2：

任何在其上选择的类图（如果有的话）的帮助将不胜感激，并且在阅读问题时可能想到的任何其他信息也将不胜感激。

Any help on which (if either) class diagram to select would be really appreciated, and any other info that may come to mind whilst reading the question would also be appreciated.

推荐答案

成功进行OO设计的关键是关注点分离。这意味着，如果您知道某些产品固有的东西，而其他与该产品的订单有关的东西，则应该将它们分开。

The key to successful OO design is separation of concerns. This means that if you know there are things that are inherent to the product and other things thar are related to an order of that product, you should separate them.

现在，在使用ERP 20年之后，我可以告诉您一次只下一个订单只是一种暂时情况。迟早您必须进行改进，因此请更好地预测是否显而易见。因此，选项2 是解决之道。

Now, after 20 years in ERP, I can tell you that one order at a time is only a temporary situation. Sooner or later, you'll have to evolve, so better anticipate if it is this obvious. So option 2 is the way to go.

现在，您应该在图中进行以下操作：

Now you should do a couple of things in your diagram:

• 首先，添加多重性。


• 仅当您确实要表达单向可导航性。对于您的情况，我建议不要这样做。


• 您在产品，订单，之间的关联供应商和外部公司与您的叙述不符。您说每个产品都有一个关联的供应商和交付公司。因此，两者之间应该有直接的联系。您还说过，供应商可以将外部公司作为母公司。因此可能会有没有任何外部母公司的订单。


• 当然，它是隐式的，但是订单中也会有一个公司。即使在给定的时间只有一个，如果将其保存在数据库中，您也将能够可靠地找到任何给定供应商的订单，甚至以前的供应商。


• 不要犹豫，为关联添加标签为图表添加表现力。因为某些关联可能看起来是多余的，但如果看其含义则根本不是。

• First, add multiplicity.
• Use arrows, only if you really want to express unidirectional navigability. In your case I srongly advise against it.
• Your associations between Product, Order, Supplier and External Company do not match your narrative. You said that each product has an associated supplier and delivery company. So there should be a direct link between those. You also said that a supplier CAN have an external company as parent. So there could be orders without any external parent company.
• Of course, it is implicit, but an order would also have a company. And even if at a given time it's only one, if you persist this in a database, you shall be able to reliably find the order of any given supplier, even former ones.
• Do not hesitate to label the associations to add expressivity to your diagram. Because some association may appear redundant, but are not at all if looking at their meaning.

现在，最后一件事：我不知道您的分配，但我建议您专注于域类，并让GUI出来。为什么呢因为一旦开始使用GUI，您肯定会拥有与产品列表之外的其他东西相关联的GUI子类。实际上，我发现它具有误导性。

Now last thing: I do not know about your assignment, but I'd advise to focus on the domain classes and let the GUI out. Why ? because once you start with the GUI, you'd certainly have GUI subclasses that are associated with other things than just the product list. As it is, I find it misleading.

这篇关于哪种班级结构最适合设置？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！