design-patterns - 包含其他类集合的类的设计(操作方法)

Question

如何设计涉及其他类集合的类？

一般示例:

一个 工作区包含 的数量项目 .
一个 项目 包含大量 资源 .
每个资源 可能包含大量文件 .

所以这里标识的类可以是 Workspace、Project、Resource 和 File。
工作区将具有项目列表。项目将具有资源列表，资源将具有文件列表。当然每个类都有其相关的设置。

现在的基本问题是:
a) 谁创建一个类并将其添加到特定集合中？另一个类或包含该集合的类？
b)另外如何跟踪特定的集合以及如何存储它们？
c) 谁审核特定集合的更改？
d) 在这种情况下可以应用哪些不同的设计模式？

基本上我想减少不同类之间的耦合。

谢谢大家

Answer 1

有很多种关系——考虑一下

汽车和车轮

汽车和司机

汽车及车主

客户和订单和订单行

学校、类(class)和类(class)实例

如果您查看 UML 建模，您将看到诸如基数和方向之类的概念以及聚合和组合之间的区别以及与相关对象的生命周期相关的问题。

因此，我们需要一系列技术和模式来处理不同类型的关系也就不足为奇了。

关于 d)。有一个最重要的原则Law of Demeter或最少知识原则。

一项重要的技术是，封装通过隐藏信息减少耦合。汽车可能对人的许多细节不感兴趣，所以我们可能在 Person 类上有一个 IDriver 接口(interface)，IDriver 提供了汽车关心的特定方法。一般原则是倾向于对接口(interface)进行编程。

之后，我们可以考虑 a)。创建。由于我们倾向于使用接口(interface)，因此使用工厂模式通常很有意义。这确实留下了谁给工厂打电话的问题。我们更喜欢:

   IPerson aPerson = myAutomobile.createDriver( /* params */);  

或者

  IPerson aPerson = aPersonFactory.create( /* params */);
  myAutomobile.addDriver(aPerson);

这里我觉得很明显，汽车对人的了解不多，所以二是更好的分工。然而，也许 Orders 可以合理地创建 OrderLines，Classes 创建 ClassInstances？

乙)。注意动向？这就是为什么我们有丰富的 Collection 类集。使用哪些取决于关系的性质(一对一、一对多等)以及我们如何使用它。所以我们根据需要选择Arrays和HashMaps等。对于 Car/Wheel，我们甚至可以使用 Car 的名称属性——毕竟 Car 正好有六个轮子(frontLeft、frontRight、backLeft、backRight、备用和转向)。如果“存储”是指持久化，那么我们正在研究关系数据库中的外键等技术。 RDBMS 和内存对象之间的映射越来越多地由良好的持久性机制(如 JPA)管理。

C)。审计？我还没有看到专门在关系级别应用审计。显然，汽车.addDriver() 方法可能非常复杂。如果有审核此操作的业务需求，那么很明显这是一个不错的地方。这只是一个围绕谁拥有信息的标准 OO 设计问题。一般原则:“不要重复自己”非常清楚，我们不希望调用 addDriver() 的每个对象都需要记住进行审计，因此这是 Auto 的工作。