存储玩家手中的扑克牌的最佳数据结构是什么？
我是 Java 初学者，目前正在为 Android 创建一款纸牌游戏，例如 gin rummy。我想知道创建 Hand 类的最佳实现是什么？存储 Deck.dealt() 返回的卡片的最佳方式是什么？
- Array
- ArrayList
- Vector
- HashSet
- LinkedList
另外，如果有人可以提供杜松子酒拉米牌开源链接，我将不胜感激。
I'm beginner in java and I'm currently creating a card game like gin rummy for Android. I want to know what's the best implementation for creating Hand class? What's the best way where to store the card returned by Deck.dealt()?
- Array
- ArrayList
- Vector
- HashSet
- LinkedList
Also, I would appreciate if anyone could provide a gin rummy open source links.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
如果您确实想了解集合类型之间的细微差别，请看这里。
List在技术上不合适，除非游戏是 Bohnanza（其中，咳咳，是有史以来最伟大的纸牌游戏之一，但我会让我完成）。List指出，除其他外，包含 A 和梅花 K 的一手牌，以及包含 K 和梅花 A 的另一手牌，基本上不是同一手牌。这对顺序的依赖比简单地“好吧，我想记住用户想要查看其卡片的顺序”要强得多，这是大量非列表集合所具有的属性，例如 LinkedHashSet代码>和番石榴的ImmutableSet。List还意味着索引 N 中的卡片具有某种特殊的意义。据我所知，没有哪张卡片游戏是这样的。Set通常不适用于纸牌游戏——仅适用于使用一副完全独特的纸牌的游戏。为了允许重复但仍然具有与顺序无关的相等性，要使用的类型是 Guava 的 Multiset。例如
HashMultiset或ImmutableMultiset。请注意，大多数多重集实现通过仅存储卡片和计数来表示多张“相等”的卡片，因此在迭代它们时，您手中的卡片的重复项必须始终一起出现。如果让用户自由控制手中牌的顺序很重要，那么您将需要LinkedListMultiset。现在课程时间结束了……好吧，说实话。调用
myHand.equals(yourHand)，或使用整只手作为Map中的键实际上并不是您想要做的事情做...所以继续使用ArrayList，你会没事的。 :-)If you really want to understand the nuances between the collection types, here goes.
Listisn't technically appropriate except when the game is Bohnanza (which, ahem, is one of the greatest card games of all time, but I'mma let me finish).Listsays, among other things, that one hand containing the Ace and King of Clubs, and another hand containing the King and Ace of Clubs, are fundamentally not the same hand. This is a much stronger dependence on order than simply "well, I want to remember the order that the user wants to see their cards in", which is a property that tons of non-List collections have, likeLinkedHashSetand Guava'sImmutableSet.Listalso implies that there is some particular significance attached to the card that sits in index N. This is true of no card game I know.Setisn't generally appropriate for card games -- only the ones that use a single deck of completely unique cards.To allow duplicates but still have order-independent equality, the type to use is Guava's
Multiset. For exampleHashMultisetorImmutableMultiset. Note that most multiset implementations represent multiple "equal" cards by storing just the card and a count, so when iterating over them, duplicates of a card you have in your hand must always appear together. If it's important to let the user freely control the order of cards in her hand, you would needLinkedListMultiset.Now that lesson time is over.... well, let's be honest. Calling
myHand.equals(yourHand), or using an entire hand as a key in aMapis not actually something you're ever going to do... so go ahead and use theArrayList, you'll be fine. :-)我认为一个好主意是使用一个接口（如果元素已排序则为 List，如果元素未排序则为 Set。您可以使用您喜欢的实现，例如：
或
I think a good idea would be to use an interface (List if element are ordered, or Set if elements are not ordered. You can use the implementation you prefer, for example:
or
将它们存储在
ArrayList中。手中的牌是按一定顺序排列的，而不是无序的一堆。此顺序通过
Set保存在List中。ArrayList还让您有机会通过索引选择特定的卡牌，这在您实现游戏时会很有帮助。请记住，只要正确设计
Hand类，您就可以在将来的任何时候轻松更改此数据结构。只要您在设计的任何类中牢记这一点，如果您意识到需要不同的东西，就可以随时更改它。Store them in an
ArrayList.Cards in a hand are in a certain order, not in an unordered pile. This ordering is preserved in a
Listover aSet.ArrayListalso gives you the opportunity to select a specific card by index, which will be helpful as you implement the game.Keep in mind that as long as you design your
Handclass properly, you can always change this data structure easily at any point in the future. As long as you keep this in mind with any class you design, you can always change it if you realize you need something different.嗯，
HashSet更快（据我所知），但如果你想制作纸牌游戏，那么也许你会希望对纸牌进行排序。这就是为什么我建议使用列表。如果您是初学者，那么最好的办法可能是使用 ArrayList。它易于使用和理解。至少这是我会做的。如果您想了解更多信息，我建议您阅读每个属性的独特属性，以便您自己做出决定。是的，就像 greuze 之前所说的那样，您应该使用接口以获得更大的灵活性。Well, a
HashSetis faster(as far as I know), but if you want to make a card game, then maybe you will wish to sort the cards. That is why I would suggest using a List. If you are a beginner, then maybe the best thing would be to use anArrayList. It's easy to use and understand. At least this is what I would do. If you want to learn more, I suggest reading about each one's unique properties so that you can decide for yourself. And yes, like greuze said before, you should use an interface for more flexibility.首先，在最新版本的 Java 中不鼓励使用 Vector，因此您可以忽略它。
其次，如果您阅读了有关其余类的 Javadoc，您就会知道，它们都有优点或缺点。有些有顺序，有些可以取重复值，有些不能，等等。因此，我认为最好的方法是为您的应用程序编写一些不基于特定类的伪代码（只需编写“将卡添加到手上”、“从手上删除卡”等内容）。一旦您掌握了一些伪代码，您将能够更清楚地看到您的需求；您想按特定顺序保留手中的牌吗？您想通过钥匙从手中取回卡片吗？
那么，你的选择就会更加清晰。
Firstly, use of Vector is discouraged in the latest versions of Java, so you can probably ignore that one.
Secondly, as you'll know if you're read the Javadoc on those remaining classes, they all have advantages or disadvantages. Some have an order, some can take duplicate values, some cannot and so on. Therefore I think the best approach is to write some pseudo-code for your application which is not based on a specific class (just write things like 'add Card to Hand', 'remove card from Hand'). Once you have some of this pseudo code you will be able to see your requirements more clearly; will you want to keep the cards in the hand in a specific order? will you want to be able to retrieve cards from the hand by a key?
Then, your choice will be clearer.
将牌组保留在列表中是有意义的，因为它确实保持了顺序。我倾向于默认使用 Lists.newArrayList() 来创建列表。列表是 Guava 的一部分。我强烈建议使用并了解 Guava，因为它有许多有用的产品。
能够将手牌保存在某种可以轻松排序的数据结构中，以便更容易比较手牌，这是有意义的。 OTOH，IIRC，金罗美牌手并没有那么大。
Keeping the deck in a List makes sense as it does maintain order. I tend to default to using Lists.newArrayList() to create a List. Lists is part of Guava. I strongly recommend using and getting to know Guava since it has many useful offerings.
It would make sense to be able to keep the hand in some data structure that could be sorted easily in order to make it easier to compare hands. OTOH, IIRC, gin rummy hands aren't all that large.