包含引用 Map 中其他键的值的 Map 是有向图的最简单形式吗？
Map<K,V<List<K>> graph = new HashMap<K,V<List<K>>();
使用它来表示可以循环的有向图是否存在任何主要障碍？
编辑：
这比应有的更令人困惑。这是一个角色扮演游戏的对话图，这是我到目前为止所拥有的。我试图确定是否可以将其重构为更简单的形式：
为 NPC 初始化：
public interface ConversationGraphI {
void init();
Map<String, DialogueNodeI> getConversation();
void setConversation(Map<String, DialogueNodeI> conversation);
}
一段对话，带有响应选项：
public interface DialogueNodeI {
String getText();
void setText(String text);
List<ResponseChoiceI> getResponseChoices();
void setResponseChoices(List<ResponseChoiceI> responseChoices);
}
一个响应选择，然后可以循环回地图中的另一段对话：
public interface ResponseChoiceI {
String getResponseText();
void setResponseText(String responseText);
String getDialogueKey();
void setDialogueKey(String dialogueKey);
}
Map<K,V<List<K>> graph = new HashMap<K,V<List<K>>();
Are there any major obstacles to using this to represent a directed graph that can be cyclical?
EDIT:
This was more confusing than it probably should have been. This is a conversation graph for an RPG, and here is what I have so far. I was trying to determine if I could refactor this into a simpler form:
Initialized for an NPC:
public interface ConversationGraphI {
void init();
Map<String, DialogueNodeI> getConversation();
void setConversation(Map<String, DialogueNodeI> conversation);
}
A piece of dialogue, with response options:
public interface DialogueNodeI {
String getText();
void setText(String text);
List<ResponseChoiceI> getResponseChoices();
void setResponseChoices(List<ResponseChoiceI> responseChoices);
}
A response choice that can then loop back to another piece of dialogue in the map:
public interface ResponseChoiceI {
String getResponseText();
void setResponseText(String responseText);
String getDialogueKey();
void setDialogueKey(String dialogueKey);
}
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我认为它的主要问题是您可能无法轻松存储有关每个边缘的数据。这取决于 V 类型的对象是否会给你这个。不过，我同意 Andrei LED 的评论，即最好使用显式边缘类型：
如果您根本不需要存储边缘元数据，那么您可以更简单：
作为 all-in- 的替代方案一种方法是，我看到由两个单独的集合表示的图，一个用于节点，一个用于边缘。如果 N 是一个节点，那么像这样：
I think the main issue with it is that you might not be able to store data about each edge easily. It depends on whether an object of type V will give you that. Still, I agree with Andrei LED's comment that it'd be better to use an explicit Edge type:
If you don't need to store edge metadata at all, then you could go even simpler:
As an alternative to the all-in-one approach, I've seen graphs represented by two separate collections, one for nodes and one for edges. If N is a node, then something like this:
好吧，我猜你必须使用 TreeMap 来让你的键按其自然顺序排序。如果不是，那么它现在将是一个非直接图，不是吗？除此之外，它是否会遵守直接图的所有其他标准将取决于您为放入其中的 Keys 和 Values 对象提供的实际实现。
Well I guess you'd have to use a TreeMap to have your keys ordered by their natural order. If not then it would be an undirect graph now wouldn't it? Other than that, whether it will respect all the other criterias of a direct graph will depend on what actual implementation you give to the Keys and Values objects you put in there.