包含其他类集合的类的设计(操作方法) [英] Design(How-to) of classes containing collections of other classes

问题描述

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

How to design classes involving collections of other classes?

一般示例:

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

A Workspace contains number of Projects .
A Project contains large number of Resources .
Each Resource may contain large number of Files.

所以这里识别的类可以是工作区、项目、资源和文件.工作区将包含项目列表.项目将包含资源列表，资源将包含文件列表.当然每个班级都有其相关的设置.

So here the classes identified can be Workspace,Project,Resource and File. Workspace will have list of Project.Project will have list of Resources and Resource will have list of Files. Of course each class has its related settings.

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

Now the basic questions are :
a) Who creates and adds a class to a particular collection? Another class or the class containing the collection?
b) Also how to keep track of a particular collection and how to store same?
c) Who audits changes to a particular collection?
d) What are the different design patterns that could be applied in such situations?

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

Basically I want to reduce the coupling between the different classes .

谢谢大家

推荐答案

关系有很多种——考虑

• 汽车和车轮
• 汽车和司机
• 汽车和注册车主
• 客户和订单和订单行
• 学校和班级以及班级的实例

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

If you look at UML modelling you'll see concepts such as Cardinality and Direction and distictions between Aggegration and Composition and questions relating to the life-cycle of the related objects.

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

It's then unsurprising that we need a range of techniques and patterns to deal with different kinds of relationships.

关于 d).有一个压倒一切的原则德米特法则或最少知识原则.

Concerning d). There's one overriding principle Law of Demeter or principle of least knowledge.

一项重要的技术是，封装通过隐藏信息来减少耦合.汽车可能对人的许多细节没有兴趣，所以我们可能在 Person 类上有一个 IDriver 接口，IDriver 提供了汽车关心的特定方法.总的原则是支持接口编程.

One important technique is then, Encapsulation decrease coupling by hiding information. Automobiles probably have little interest in many details of people, so we might have a IDriver interface on our Person class, IDriver offers the particular methods that Automobile cares about. The general principle being to favour programming to interfaces.

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

Following that through, we can think about a). Creation. As we're tending to use Interfaces, it often makes sense to use Factory patterns. That does leave the question of who calls the factory. Do we prefer:

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

或

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

这里我认为很明显，汽车对人的了解不多，因此第二个是更好的职责分工.然而，也许订单可以合理地创建订单行，类创建类实例?

Here I think it's pretty clear that Automobiles don't know much about people, and therefore the second is better division of responsibilities. However maybe Orders could reasonably create OrderLines, Classes create ClassInstances?

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

b). Keeping track? That's why we have rich sets of Collection classes. Which ones to use depend upon the nature of the relationship (one-one, one-many; etc.) and how we use it. So we pick Arrays and HashMaps etc. according to need. For a Car/Wheel we might even use names attributes of the Car - after all a Car has exactly six wheels (frontLeft, frontRight, backLeft, backRight, spare and steering). If by "store" you mean persist, then we're looking at techniques such foreign keys in a relational database. Mapping between RDBMS and in-memory objects is increasingly managed by nice persistence mechanisms such as JPA.

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

c). Audit? I've not seen auditing applied specifically at a relationship level. Clearly the automobile.addDriver() method may be arbitrarily complex. If there's a business requirement to audit this action, then it's pretty clear that this a decent place to do it. This is just a standard OO design question revolving around who owns the information. General principle: "Do Not Repeat Yourself" so pretty clearly we don't want every object that calls addDriver() to need to remember to audit, hence it's Auto's job.

这篇关于包含其他类集合的类的设计(操作方法)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！