收集作为现实世界容器的隐喻

Question

我发现使用集合建模物理容器非常直观。我根据物理属性覆盖/委托添加方法，添加容量限制，例如添加元素的量，基于物理属性的排序，使用位置到元素的映射定位元素等等。

然而，当我阅读集合类的文档时，我得到的印象是它不是预期的用途，它只是一个数学结构，而有界队列只是意味着受到元素数量的限制等等。

的确，我认为除非我能够连贯地对这个集合进行建模，否则我不应该将这个类作为集合公开，而只是在内部委托它。意见？

Answer 1

软件开发中的许多结构都没有物理对应物。实际上，一些结构和算法是相当抽象的，并且不直接在物理世界中对对象进行建模。因为对象不能作为现实世界中物理对象的合适模型，并不一定意味着它不能有效地用于解决计算机程序中的问题。

Answer 2

  

的确，我认为除非我能够连贯地对这个集合进行建模，否则我不应该将这个类作为集合公开，而只是在内部委托它。意见？

首先，您不希望过多地使用软件工程的建模方面。 UML样式模型（通常）主要用于组织和表达开发人员关于如何实现应用程序的高级想法。模型中的类与应用程序代码中的实现类之间不需要严格的一对一关系。

其次，你不想过于担心建模“真实世界”（即物理）对象及其行为。在典型应用中使用的大多数“对象”与现实世界没有真正的联系。例如，“文件夹”或“目录”实际上只不过是具有相同名称的物理对象的类比。通常不需要计算机概念受现实世界对象的物理行为约束。

最后，有许多软件工程原因导致您的Java域类扩展标准集合类型是一个坏主意。例如：

• 集合具有通用行为，通常不适合在域对象中公开。例如，您通常不希望随意添加和删除域对象的组件。

• 通过扩展集合类型，您隐式授予应用程序某些部分的权限，以将域对象视为只列表或集合或其他任何内容。

• 通过扩展集合类，您可以将实现细节硬连接到域API中。例如，您需要在扩展ArrayList或LinkedList之间做出决定，并且改变您的想法会导致（至少）二进制API不兼容......并且可能更糟。

Answer 3

我不完全确定我是否理解正确。我想知道你是否应该公开集合（子类化）或包装它（有一个私有字段）。 正如罗伯特所说，这实际上取决于案件。这几乎是你的选择。尽管如此，我认为在许多情况下，更好的选择是不公开集合，因为约束定义了您正在建模的对象，并且与底层集合不完全一致。简而言之：您的对象的用户不应该知道他们正在处理集合，除非它真的具有某些特殊性的集合，例如拥有集合的所有属性，但只允许一定数量的对象。