OO设计：是否应该存储集合？

Question

我在很多不同的情况下都想知道这一点，所以我来这里寻找专家的知识。 让我们说我必须建模需要收集的东西。一个简单的例子：一个应用程序，存储着名的引号及其作者和一组标签或关键字。用户应该能够输入标签或关键字并获得匹配的报价。 我的问题是：我真的需要一个包含我的引号集的类吗？像这样的东西：

或者这也是正确的吗？

我以更抽象的方式提出这个问题（毕竟，UML永远不应该依赖于实现）。 我一直认为第二个例子（只有一个类）是不正确的，但现在我想，也许用户可以按某个界面上的按钮而该按钮会执行一些代码，这些代码会将某个引用存储在某个地方，第二个例子也是正确的？

基本上，我是否应该总是将某个集合存储在某个地方，即使存储类除了存储集合之外什么都不做（并提供访问它的方法）？

Answer 1

如果没有强有力的理由要有另一个容器类（特别是在抽象概念级别），我肯定只选择一个类。然后我将收集方法添加为静态函数。一个单独的容器类只会带来更多的复杂性，更多的依赖性和像你一样的怀疑。 :)怀疑经常表明缺乏真正的需要。当你真的需要什么时，你就会知道。

这里有一些例子，有一些解释。我发现它简单，清晰，优雅和抽象，意味着非限制性，易于转换为您喜欢的任何实现：

当谈到这个班级与其他班级的关系时，你最初会有你的收藏，而不会引入新的班级。该图显示了两个示例。 ＆＃34;其他课程＆＃34;实际上看到了一个集合＆＃34;引用＆＃34;这是有序的，像Vector。 ＆＃34;再多上一班＆＃34;还有一系列具有不同特征的行情。

稍后在实现级别上，您可以直接实现它，或者最终根据具体，实现限制和特殊要求添加Factory或Container类。