设计（如何）包含其他类的集合的类 [英] Design(How-to) of classes containing collections of other classes

问题描述

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

常规示例：

A 工作空间包含项目的数量。

一个项目包含大量的资源。

每个资源可能包含大量的文件。

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

现在基本的问题是：

a）谁创建并添加一个类到一个特定的集合？另一个类还是包含该集合的类？

b）还如何跟踪特定的集合以及如何存储相同？

c）谁审核对特定集合的更改？ >
d）在这种情况下可以应用的不同设计模式是什么？

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

感谢大家

解决方案

有很多种关系 - 考虑

• 汽车和轮子


• 汽车和司机


• 汽车和注册所有者


• 客户和订单与订单行


• 课程类和课程实例

如果您查看UML建模，您将看到概念，如基数和方向以及Aggegration和Composition之间的相互矛盾以及与相关对象的生命周期相关的问题。

那么我们需要一系列的技术和模式来处理不同的关系，那就不足为奇了。

关于d）。有一个最重要的原则是德米特法案或最不了解的原则。

然后，一个重要的技术是封装通过隐藏信息减少耦合。汽车可能对人们的许多细节没有兴趣，所以我们可能在我们的Person类中有一个IDriver界面，IDriver提供了汽车关心的特定方法。一般原则是希望编程接口。

之后，我们可以考虑一下。创建。当我们倾向于使用Interfaces时，通常使用Factory模式是有意义的。这确实留下了谁来电的厂家的问题。我们喜欢：

  IPerson aPerson = myAutomobile.createDriver（/ * params * /）; 
  

或

  IPerson aPerson = aPersonFactory.create（/ * params * /）; 
 myAutomobile.addDriver（aPerson）; 
  

这里我很清楚，汽车对人不太了解，因此第二个是更好地分工。但是也许Orders可以合理地创建OrderLines，Classes创建ClassInstances？

b）。注意动向？这就是为什么我们有丰富的集合类。哪些使用取决于关系的性质（一对一，一等等）以及我们如何使用它。所以我们根据需要选择数组和散列图等。对于汽车/车轮，我们甚至可以使用汽车的名称属性 - 毕竟一辆汽车有六个轮子（frontLeft，frontRight，backLeft，backRight，备用和转向）。如果通过store表示持久化，那么我们在关系数据库中查看这些外键的技术。 RDBMS和内存中对象之间的映射越来越多地通过诸如JPA之类的持久性机制来管理。

c）。审计？我没有看到审计专门应用于关系层面。显然，autom.addDriver（）方法可能是任意复杂的。如果有业务要求来审核这一行动，那么很明显这是一个体面的做法。这只是一个标准的OO设计问题，围绕谁拥有这些信息。一般原则：不要重复自己非常清楚，我们不希望调用addDriver（）的每个对象都需要记住审核，因此它是Auto的工作。

How to design classes involving collections of other classes?

General Example:

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.

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 .

Thanks Everyone

解决方案

There are many kinds of relationships - consider

• Automobile and Wheels
• Automobile and Driver
• Automobile and Registered Owner
• Customer and Order and Order Line
• School and Class and instance of Class

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.

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

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.

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 */);  

or

  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). 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). 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屋！