简单应用程序的类图答案

【问题标题】：Class diagram for a simple application简单应用程序的类图
【发布时间】：2012-03-21 18:27:35
【问题描述】：

假设我们有 3 个实体：Library、Section 和 Book。

一个Library 由几个Sections 组成。一个Section 有几个Books。

Book 可能只属于 1 个Section。最后一个Section 可能只属于1 个Library。

我的看法是 Library 类聚合 Sections 的集合和 Section 类聚合 Books 的集合。 p>

现在我需要将所有图书上传到服务器。我构建了一个类BookUploader，它在其构造函数中接收一个Book 对象。在服务器上，我为每个库创建了一个文件夹，在每个库中，我将创建一个 Section 文件夹并将 Book 放入其中。

问题是因为我将 Book 对象传递给 BookUploader 我不知道它的 Section 是什么。另外我不知道哪个Section属于哪个Library。

所以我想我只是将 Library 对象传递给 BookUploader，然后循环所有部分，然后循环每个部分中的所有书籍，但有人告诉我，现在 BookUploader 依赖 3 个类来上传一本书，这是一个糟糕的设计。

他建议每个 Book 对象都应该保存它的 Section，每个 Section 都应该保存它的 Library，这与我的原始设计完全相反。

谁能分享他对哪种设计更好以及为什么更好的想法？

提前致谢。

【问题讨论】：

您的设计如何强制将“书”放在一个部分中？你的意思是它强制一本书的一个实例在一个部分中吗？如果是这样，那是真的，但是同一本书的多个“副本”呢，除非您始终小心地正确构建它们，否则它们可能会分布在多个部分中。由于您正在模拟现实世界的情况，因此请考虑在现实世界中如何处理它。一本书几乎总是以某种方式印有图书馆和部门信息，图书馆/部门也可能有一个可用书籍的列表......
@Chad 是的，在我的设计中，一本书只有一个副本。我的问题是哪个对象应该包含另一个？ Library 对象应该包含一个 Sections 的集合还是每个 Section 都应该包含一个 Library 对象？
这似乎非常合适，但回到您关于如何处理图书->图书馆关系的原始问题（与您迄今为止尝试建模的内容相反）。假设（IRL）你在外面的地上找到一本图书馆的书。你怎么知道这是图书馆的书？书上有什么标记要告诉你吗？我敢打赌……
@Chad +1 实际上你是对的。每本书都应该知道它的图书馆。我缺少的是孩子中的一个函数来获取对父母的引用。简单的一点，但是一旦你掌握它就真的很有意义：D

【解决方案1】：

将聚合定义为双向关联的一端并没有错。（以here 或here 为例。）

如果您正在寻找实现细节，请查看例如在 EReferences 中 ecore 的 EOpposite 功能。

【讨论】：

【解决方案2】：

阅读@Chad 的评论后，我意识到设计本身需要对相关实体进行一些修改。缺少的是每个子类中的一个函数，该函数将返回对其父类的引用。

【讨论】：