Ami*_*itd 5 abstraction design-patterns class-design
如何设计涉及其他类集合的类？
一般例子:
一个工作区包含数项目.
一个项目包含了大量的资源.
每个资源可能包含大量文件.
所以这里确定的类可以是Workspace,Project,Resource和File.Workspace将包含Project.Project列表,其中包含Resources和Resource列表.当然每个班级都有相关的设置.
现在基本的问题是:
a)谁创建并添加了一个特定集合的类？另一个类或包含该集合的类？
b)另外如何跟踪特定的集合以及如何存储它？
c)谁审核特定馆藏的变化？
d)在这种情况下可以应用哪些不同的设计模式？
基本上我想减少不同类之间的耦合.
感谢大家
有很多种关系 - 考虑一下
如果你看一下UML建模,你会看到诸如基数和方向以及Aggegration和Composition之间的distictions以及与相关对象的生命周期有关的问题等概念.
因此,我们需要一系列技术和模式来处理不同类型的关系,这一点不足为奇.
关于d).德米特定律或最少知识原则有一个最重要的原则.
一个重要的技术是,封装通过隐藏信息来减少耦合.汽车可能对人的许多细节没什么兴趣,所以我们可能在Person类上有一个IDriver接口,IDriver提供了汽车关心的特定方法.一般原则是支持编程到接口.
在此之后,我们可以考虑a).创建.由于我们倾向于使用Interfaces,因此使用Factory模式通常是有意义的.这确实留下了谁叫工厂的问题.我们更喜欢:
IPerson aPerson = myAutomobile.createDriver( /* params */);
要么
IPerson aPerson = aPersonFactory.create( /* params */);
myAutomobile.addDriver(aPerson);
在这里我认为很明显,汽车对人们了解不多,因此第二是更好的责任分工.但是Orders可以合理地创建OrderLines,Classes创建ClassInstances？
B).注意动向？这就是我们拥有丰富的Collection类集的原因.使用哪些取决于关系的性质(一对一,一对多;等等)以及我们如何使用它.所以我们根据需要选择Arrays和HashMaps等.对于汽车/轮子,我们甚至可以使用汽车的名称属性 - 毕竟汽车有六个轮子(frontLeft,frontRight,backLeft,backRight,备用和转向).如果通过"store"表示持久化,那么我们在关系数据库中查看这些外键的技术.RDBMS和内存中对象之间的映射越来越多地通过诸如JPA之类的良好持久性机制来管理.
C).审计？我没有看到在关系级别专门应用审计.显然,automobile.addDriver()方法可能是任意复杂的.如果审计此操作有业务需求,那么很明显这是一个体面的地方.这只是围绕谁拥有这些信息的标准OO设计问题.一般原则:"不要重复自己"这么清楚我们不希望每个调用addDriver()的对象都需要记住审计,因此它是Auto的工作.