更新：请在设计原则、优雅、意图表达的背景下阅读此问题，尤其是通过设计选择发送给其他程序员的“信号”。
我有一组对象的两个“视图”。一种是通过字符串值索引对象的字典/地图。另一个是按序数（排序整数）索引对象的字典/地图。没有对象的“主”集合本身可以作为对象数量的权威来源，但是两个字典都应该始终包含对所有对象的引用。
当一个新项目被添加到集合中时，一个引用被添加到两个字典中，然后需要进行一些受新对象总数影响的处理。
我应该使用什么作为权威来源来参考对象集的当前大小？似乎我所有的选择在一个维度上都存在缺陷。我可以始终如一地参考其中一本词典，但这将暗示该词典优于另一本。我可以添加第三个集合，一个简单的对象列表作为权威列表，但这会增加冗余。存储运行计数似乎最简单，但也增加了冗余，并且比动态引用集合的自跟踪计数更脆弱。
是否有其他选择可以让我避免选择较小的邪恶，或者我必须接受优雅的妥协？
我建议封装：创建一个隐藏“管理”细节（例如当前计数）的类，并使用它来公开两个集合的不可变“视图”。
客户将向“manglement”对象询问对其中一个集合的适当引用。
向集合添加“术语”（因为没有更好的词）的客户端将通过“manglement”对象来完成。
这样，您的假设和实现选择对服务的客户端“隐藏”，并且您可以记录大小/计数的集合选择是任意的。未来的维护者可以在不破坏客户端的情况下更改计数的管理方式。
顺便说一句，是的，我的意思是“manglement”——我最喜欢的管理不当（在任何情况下！）
我将创建一个具有（至少）两个集合的类。
该课程将处理细节管理：
这样，您可以在需要任何一种行为的任何地方使用相同的集合，但仍然抽象出您想要的“索引”行为。
单独的类为您提供了一个接口，用于解释您对如何使用该类的意图。
如果两个字典都包含对每个对象的引用，那么它们的计数应该相同，对吗？如果是这样，只需选择一个并保持一致。
我不认为这有什么大不了的。每次需要访问它们时，只需以相同的顺序引用它们。
如果你真的担心它，你可以用一个暴露公共接口的包装器来封装集合——比如
这样，它将始终是一致的和原子的——或者至少你可以这样实现它。
但是，我不认为这有什么大不了的。