c# - 具有多个互相引用的集合的容器类的设计实践

Question

我正在尝试设计一个具有以下内容的类结构:

• Container 类，保存所有项目。
• Item 集合类，位于 Container 内部，其中每个 Item 都有一个唯一的 ID 和一些其他数据，包括对 ItemStyle 的引用。
• ItemStyle集合类，位于Container内部，其中每个ItemStyle代表项目的通用样式以及与其他样式的关系。

关系可以是“附加到”，其中样式具有可以附加到的其他样式的列表，以及与此相反的“附件”。如果一个样式可以“附加到”另一个样式，那么另一个样式应该能够生成第一个样式作为其“附件”之一。

容器管理 Items 和 ItemStyles。我对所有内容都使用唯一的 ID，因为我希望能够与 XML 进行序列化。

但是，我不断遇到逻辑问题，例如我试图从 XML 反序列化 ItemStyle，但它当然无法生成对其读取的项目 ID 的引用，因为只有容器本身可以访问其他项目。

另一个问题是我希望这些类是独立的，如果我有一个项目的引用，我可以调用兼容项目的列表，例如调用“Item.Attachments”或“Item.AttachesTo”。当然，这一切都需要由 Container 计算，因为它是唯一能够访问 ItemStyles 和 Item 集合的类。

因此，我遇到了一个解决方案，我必须为每个 Item 和 ItemStyle 提供对 Container 的引用，以便它们可以执行自己的查找并确定它们与其他项的关系。这看起来像是糟糕的封装和糟糕的 OOP 实践，但我想不出任何其他方法。

我正在尝试将我的代码与 ListView 的工作方式作为示例进行比较。 ListView 具有 ListViewItemCollection 和 ListViewItems。在用户代码中，当您可以创建新的 ListViewItem 并将其添加到 ListViewItemCollection 时，它现在会自动拥有对其父 ListView 的引用。查看元数据时，它显示 ListView 引用仅具有 getter。我可以假设它使用内部集吗？

遵循所有者/项目关系的 ListView 模型是否适用于我的类？

Answer 1

考虑到所有涉及的类之间的紧密耦合，我认为引用父级(Container)并不是一个坏主意。有许多模型依赖于父级引用(典型的原因可能是确保单个父级，但其他原因(例如验证等)也可能是一个原因) - 建模的方法之一是拥有非公共(public)构造函数并通过以下方式构造对象:工厂方法。另一种建模方法是使用公共(public)构造函数，但使用内部 setter 来设置父引用。每当将子级添加到父级的集合对象时，就会设置引用。

我更喜欢后一种方法。然而，我要做的一件事是避免与容器直接耦合。相反，我将介绍 IContainer 接口(interface)，该接口(interface)将抽象子项中所需的查找，并且子项 (Item/ItemStyle) 将仅了解 IContainer 接口(interface)。

另一种合理的设计是当 children 想要查找时引发他们的事件。这些将是内部事件，当将子级添加到容器中时，容器将处理这些事件。

另一种方法是采用松散模型。本质上，Item 可以维护自己的ItemStyle 引用。无论何时需要，Container 都可以通过实现访问者模式来构建 ItemStyle 集合。