Java 集合作为真实世界容器的隐喻

我发现使用集合对物理容器进行建模非常直观。我使用基于物理属性（如添加元素的体积）的附加容量约束重写/委托add方法，基于物理属性进行排序，使用位置到元素的映射定位元素，等等

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

---

事实上，我认为除非我能够对这个集合进行一致的建模，否则我可能不应该将这个类作为集合公开，而应该只在内部委托给它。观点？

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

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

事实上，我认为除非我能够对这个集合进行一致的建模，否则我可能不应该将这个类作为集合公开，而应该只在内部委托给它。意见

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

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

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

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

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

• 通过扩展集合类，可以将实现细节硬连接到域API中。例如，您需要决定是扩展

  ArrayList

  还是

  LinkedList

  ，而改变主意至少会导致二进制API不兼容。。。可能更糟

---

同意。实际上，尽管有很多猫/狗/动物的例子，你最不想用面向对象技术建模的是真实世界。员工成为经理，客户成为供应商，这一切都太容易了，以至于OO建模对他们来说没有任何实际用途。感谢您的回复。我在这里想的是一个链表的装饰器，它除了检查允许的项目数量外，还检查物理容量。当然，它应该是可移植的，并且允许插入、删除和排序。我至少清楚地知道，在内部需要这样做。也就是说，我的decorator至少是一个内部类。容器作为一个整体可能比集合更复杂，因此不应扩展集合。