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

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

或者这也是正确的

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

---

基本上，我是否应该始终将集合存储在某个位置，即使存储类只存储集合（并提供访问它的方法）而不做任何其他操作？

如果没有足够的理由拥有另一个容器类（特别是在抽象概念级别），我肯定只喜欢一个类。然后我将收集方法添加为静态函数。单独的容器类只会带来更多的复杂性、更多的依赖性和疑虑，就像您的一样。：）怀疑往往表明缺乏真正的需要。当你真的需要什么的时候，你就知道了

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

当涉及到这个类和另一个类的关系时，您实际上拥有了您的集合，而不引入新类。此图显示了两个示例。“其他类”实际上看到一个有序的集合“引号”，如Vector。“One more class”还包含一组具有不同特征的引号

---

稍后在实现层，您可以像这样直接实现它，或者根据具体的实现要求和特殊要求，最终添加工厂或容器类。

我从来没有想过静态方法解决方案！很酷很简单。谢谢还有一条评论：在这种情况下，我肯定需要一个静态属性来存储我的集合，对吗？否则就无法存储create（）方法的返回值（如果我没有弄错的话，这个方法会创建集合）。不，根本没有静态属性，至少不是为了这个目的。Static create（）只需创建一个新引用的新实例，并将其返回给调用方，无论它是哪一个调用方！它通常是另一个类。我仍然在想：P如果在存储集合的地方没有静态属性，那么您确实需要另一个类来存储它，对吗？如果这是整个应用程序（没有其他类），那么它需要静态集合属性吗？否则，当您想要访问“Quote”对象集合时，我看不到它将存储在哪里。对不起，我有点糊涂了！如果您有一个参考底图数据库或任何其他外部存储，“集合”实际上在数据库中，并且您始终可以通过简单的SQL查询或类似方式（如所述，以静态方法实现）检索对象。如果对象位于内存中（没有DB），则需要一个私有静态数据成员来保留对给定类的所有实例的引用。