命名以可预测的顺序存储密钥的字典结构？ [英] Naming a dictionary structure that stores keys in a predictable order?
问题描述
注意：虽然我的特定上下文是Objective-C，但我的问题实际上超出了编程语言的选择。此外，我把它标记为主观，因为有人必然会抱怨，但我个人认为这几乎完全是客观的。此外，我知道这个相关的SO问题，但由于这是一个更大的问题我认为更好地让这是一个单独的问题。请不要批评这个问题，没有充分阅读和理解。谢谢！
Note: Although my particular context is Objective-C, my question actually transcends programming language choice. Also, I tagged it as "subjective" since someone is bound to complain otherwise, but I personally think it's almost entirely objective. Also, I'm aware of this related SO question, but since this was a bigger issue, I thought it better to make this a separate question. Please don't criticize the question without reading and understanding it fully. Thanks!
我们大多数人都熟悉 字典抽象数据类型，无论我们称之为地图，字典，关联数组，散列等，这取决于我们选择的语言。字典的简单定义可以由三个属性来总结：
Most of us are familiar with the dictionary abstract data type that stores key-value associations, whether we call it a map, dictionary, associative array, hash, etc. depending on our language of choice. A simple definition of a dictionary can be summarized by three properties:
- 值通过键访问（与索引相反，如数组
- 每个键都与一个值相关联。
- 每个键都必须是唯一的。
任何其他属性可以说是特定目的的便利或专业化。例如，一些语言（特别是PHP和Python等脚本语言）会模糊字典和数组之间的界限，并为字典提供排序。有用的是这样的，这样的添加不是字典的基本特征。在一个纯粹的意义上，字典的实际实现细节是无关紧要的。
Any other properties are arguably conveniences or specializations for a particular purpose. For example, some languages (especially scripting languages such as PHP and Python) blur the line between dictionaries and arrays and do provide ordering for dictionaries. As useful as this can be, such additions are not a fundamental characteristics of a dictionary. In a pure sense, the actual implementation details of a dictionary are irrelevant.
对于我的问题，最重要的观察是，键被枚举的顺序没有定义 - 一个字典可以按照它找到最方便的顺序提供密钥，由客户根据需要进行组织。
For my question, the most important observation is that the order in which keys are enumerated is not defined — a dictionary may provide keys in whatever order it finds most convenient, and it is up to the client to organize them as desired.
我创建的自定义词典，它强加了特定的关键顺序，包括自然的排序顺序（基于对象比较）和插入顺序。在 SortedDictionary （我实际已经实现）中，将前一个变体命名为很明显，但是后者更有问题。我看到 LinkedHashMap 和 LinkedMap （Java），< a href =http://msdn.microsoft.com/en-us/library/system.collections.specialized.ordereddictionary.aspx =nofollow noreferrer> OrderedDictionary （.NET）， OrderedDictionary （Flash）， OrderedDict （Python），和 OrderedDictionary （Objective-C）。其中有些更成熟，有些则是更多的概念验证。
I've created custom dictionaries that impose specific key orderings, including natural sorted order (based on object comparisons) and insertion order. It's obvious to name the former some variant on SortedDictionary (which I've actually already implemented), but the latter is more problematic. I've seen LinkedHashMap and LinkedMap (Java), OrderedDictionary (.NET), OrderedDictionary (Flash), OrderedDict (Python), and OrderedDictionary (Objective-C). Some of these are more mature, some are more proof-of-concept.
LinkedHashMap 根据Java集合传统中的实现而命名 - 链接，因为它使用双向链接列表来跟踪插入顺序，而哈希是因为它对HashMap进行子类化。除了用户不需要担心的事实之外，类名称甚至不表示它的作用。使用有序似乎是现有代码中的一致性，但是关于此主题的网络搜索也显示了有序和排序之间可以理解的混淆，我感觉一样。 .NET实现甚至有一个关于明显的不当行为的评论，并建议它应该是IndexedDictionary，因为您可以在订单中的特定点检索和插入对象。
LinkedHashMap is named according to implementation in the tradition of Java collections — "linked" because it uses a doubly-linked list to track insertion order, and "hash" because it subclasses HashMap. Besides the fact that user shouldn't need to worry about that, the class name doesn't really even indicate what it does. Using ordered seems like the consensus among existing code, but web searches on this topic also revealed understandable confusion between "ordered" and "sorted", and I feel the same. The .NET implementation even has a comment about the apparent misnomer, and suggests that it should be "IndexedDictionary" instead, owing to the fact that you can retrieve and insert objects at a specific point in the ordering.
我正在设计一个框架和API，我想要尽可能智能地命名该类。从我的观点来看，索引可能会工作（取决于人们如何解释它，并根据广告的字典功能），已订购是不精确的，具有太多的潜力混淆和链接是正确的（向Monty Python道歉）。 ; - ）
I'm designing a framework and APIs and I want to name the class as intelligently as possible. From my standpoint, indexed would probably work (depending on how people interpret it, and based on the advertised functionality of the dictionary), ordered is imprecise and has too much potential for confusion, and linked "is right out" (apologies to Monty Python). ;-)
作为用户，什么名字对你来说最有意义？有没有一个特定的名字，说明了什么类是什么？ （我不反对使用稍长的名字，如InsertionOrderDictionary如果适用）。
As a user, what name would make the most sense to you? Is there a particular name that says exactly what the class does? (I'm not averse to using slightly longer names like InsertionOrderDictionary if appropriate.)
编辑：另一个强大的可能性（在我的答案下面讨论）是 IndexedDictionary 。我不喜欢插入顺序，因为如果您允许用户在特定索引处插入键，重新排序键等，这并不重要。
Another strong possibility (discussed in my answer below) is IndexedDictionary. I don't really like "insertion order" because it doesn't make sense if you allow the user to insert keys at a specific index, reorder the keys, etc.
推荐答案
我投票OrderedDictionary，原因如下：
I vote OrderedDictionary, for the following reasons:
索引从未在Cocoa类中使用，除了一个实例。它总是显示为一个名词（NSIndexSet，NSIndexPath，objectAtIndex :, etc）。当索引出现为动词时，只有一个实例，它在NSPropertyDescription的索引属性上：isIndexed和setIndexed。 NSPropertyDescription大致类似于数据库中的表列，其中索引是指优化以加快搜索时间。因此，使用NSPropertyDescription作为Core Data框架的一部分，isIndexed和setIndexed将等价于SQL数据库中的索引。因此，称之为IndexedDictionary似乎是冗余的，因为数据库中的索引被创建以加快查找时间，但已经有一个字典具有O（1）查找时间。但是，称之为IndexDictionary也可能是一个误导，因为Cocoa中的index指的是位置，而不是顺序。两者在语义上是不同的。
"Indexed" is never used in Cocoa classes, except in one instance. It always appears as a noun (NSIndexSet, NSIndexPath, objectAtIndex:, etc). There is only one instance when "Index" appears as a verb, which is on NSPropertyDescription's "indexed" property: isIndexed and setIndexed. NSPropertyDescription is roughly analogous to a table column in a database, where "indexing" refers to optimizing to speed up search times. It would therefore make sense that with NSPropertyDescription being part of the Core Data framework, that "isIndexed" and "setIndexed" would be equivalent to an index in a SQL database. Therefore, to call it "IndexedDictionary" would seem redundant, since indices in databases are created to speed up lookup time, but a dictionary already has O(1) lookup time. However, to call it "IndexDictionary" would also be a misnomer, since an "index" in Cocoa refers to position, not order. The two are semantically different.
我明白你对OrderedDictionary的关注，但是先例已经在Cocoa中设置了。当用户想要维护一个特定的序列时，他们使用有序： - [NSApplication orderedDocuments]， - [NSWindow orderedIndex]， - [NSApplication orderedWindows]等等。所以，John Pirie主要是正确的想法。
I understand your concern over "OrderedDictionary", but the precedent has already been set in Cocoa. When users want to maintain a specific sequence, they use "ordered": -[NSApplication orderedDocuments], -[NSWindow orderedIndex], -[NSApplication orderedWindows], etc. So, John Pirie has mostly the right idea.
但是，您不希望在字典中插入用户的负担。他们希望创建一个字典一次，然后让它保持适当的顺序。他们甚至不想以特定的顺序请求对象。订单规范应在初始化期间完成。
However, you don't want to make insertion into the dictionary a burden on your users. They'll want to create a dictionary once and then have it maintain an appropriate order. They won't even want to request objects in a specific order. Order specification should be done during initialization.
因此，我建议使OrderedDictonary成为一个类集群，其中包含InsertionOrderDictionary和NaturalOrderDictionary以及CustomOrderDictionary的私有子类。然后，用户只需创建一个如下所示的OrderedDictionary：
Therefore, I recommend making OrderedDictonary a class cluster, with private subclasses of InsertionOrderDictionary and NaturalOrderDictionary and CustomOrderDictionary. Then, the user simply creates an OrderedDictionary like so:
OrderedDictionary * dict = [[OrderedDictionary alloc] initWithOrder:kInsertionOrder];
//or kNaturalOrder, etc
对于CustomOrderDictionary，您可以让他们给你比较选择器，甚至（如果它们正在运行10.6）一个块。我认为这将为未来扩展提供最大的灵活性，同时仍然保持适当的名称。
For a CustomOrderDictionary, you could have them give you a comparison selector, or even (if they're running 10.6) a block. I think this would provide the most flexibility for future expansion while still maintain an appropriate name.
这篇关于命名以可预测的顺序存储密钥的字典结构？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
