集合作为现实世界容器的隐喻答案

【问题标题】：Collection as a metaphor for real world containers集合作为现实世界容器的隐喻
【发布时间】：2010-08-14 14:26:23
【问题描述】：

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

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

确实，我认为除非我能够连贯地为这个集合建模，否则我可能不应该将这个类公开为一个集合，而只能在内部委托给它。意见？

【问题讨论】：

感谢您的回复。我真的在这里考虑链接列表的装饰器，除了允许的项目数量之外，它还检查物理容量。当然它应该是可迭代的，并且允许插入、删除和排序。我至少清楚内部需要这个。也就是说，我的装饰器至少会是一个内部类。容器作为一个整体可能比集合更复杂，因此不应该扩展一个。

标签： java collections dns data-modeling

【解决方案1】：

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

【讨论】：

【解决方案2】：

确实，我认为除非我能够连贯地为这个集合建模，否则我可能不应该将这个类公开为一个集合，而只能在内部委托给它。意见？

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

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

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

集合具有一般行为，通常不适合在域对象中公开。例如，您通常不希望随意添加和删除域对象的组件。
通过扩展集合类型，您隐式授予应用程序的某些部分将域对象视为只是列表或集合或其他任何内容的权限。
通过扩展集合类，您可以将实现细节硬连接到您的域 API 中。例如，您需要在扩展 ArrayList 或 LinkedList 之间做出决定，而改变主意会（至少）导致二进制 API 不兼容……甚至可能更糟。

【讨论】：

同意。实际上，您想要使用 OO 技术建模的最后一件事就是现实世界，尽管那里有所有猫/狗/动物的例子。员工很容易成为经理，而客户很容易成为供应商，因此对他们进行 OO 建模根本没有任何实际用途。

【解决方案3】：

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

【讨论】：