TreeMapKey, Values 是成对实例化的。对我来说，Key是一个 IP 地址，而Values 是包含有关该 IP 地址的统计信息的对象。
是否有理由冗余存储对象Key内部Value？我很想节省空间并将其排除在外，但直观地说，没有Key对象内部感觉是错误的（为了良好的封装）。
问问题
776 次
4 回答
3
请记住，包含键只会将值对象的大小增加 32 位或 64 位（取决于您使用的是 32 位还是 64 位 JVM），因此决定是否包含它可能不会对您的程序的内存消耗产生重大影响 - 因此我会在包含它而不是不包含它方面犯错。
于 2013-07-20T22:33:41.447 回答
3
您的设计存在缺陷-您处于“拒绝对象”状态。
您应该创建一个类来保存详细信息，包括 IP 地址。
如果您想快速检索给定 IP 地址的详细信息，您可以使用 IP 地址作为键将它们存储在 Map 中。
在某种程度上，这就是您要问的，因为映射中使用的键存储在值对象中。只是通过适当的设计，键已经是存储在值中的对象的一部分。
于 2013-07-20T23:24:48.603 回答
2
是否有理由将 Key 冗余存储在 Value 对象中？
首先，您不会将键存储在值对象“内部”。相反，值对象将具有对键对象的引用。因此，您根本不会存储冗余副本。（或者至少，除非你故意复制/克隆关键对象......这将是相当愚蠢的。）
唯一的问题是对值对象中键的引用是否是“冗余的”。从某种意义上说确实如此，但另一方面是冗余可能会简化您的代码......并可能使其在其他地方更有效。如果不查看这些对象在您的代码中（其他地方）的使用方式，我们就无法对此做出判断。但是很可能无论如何它并没有太大的区别。见下文。
我很想节省空间并将其排除在外，但直观地说，在对象中没有 Key 感觉是错误的（为了良好的封装）。
在值中没有对键的引用所节省的空间是每个值一个字（32 或 64 位）。即使您拥有数百万个这样的对象，这很可能太小而无需担心。现实情况是，对于给定的 key + value + map 条目，一个额外的单词可能不到每个对象空间使用总量的 5%。那 5% 不太可能产生重大影响……
封装的问题取决于上下文。这实际上取决于封装边界的位置以及它们的多孔性。封装不是最终目标。它是可用于设计/实现可维护软件的一组“工具”之一。它并不总是正确的工具，当然必须适当地使用它；即清楚地了解它如何帮助（或阻碍）手头的问题。
但这里有一个想法：您可以将“值”对象作为Map... 中的键和值，并使用Comparator. 根据详细信息，这将允许您将 IP 地址（等）完全隐藏在封装边界内。（这种方法虽然不适用于HashMap...）
最后一条建议。
您似乎正在做有经验的开发人员会认为是“过早的优化”。这通常是个坏主意。我的建议是暂时不要担心空间使用情况。
等到你的应用程序开始工作，你就可以用真实的输入数据进行基准测试了。
基准测试并查看性能（即内存使用）是否可以接受。
如果（且仅当）它是不可接受的，则分析应用程序以寻找减少内存使用的机会。
实施并重新运行基准测试，看看它是否有所作为。
根据需要重复。
于 2013-07-21T01:45:46.117 回答
0
如果键将与值对象一起在应用程序的其他任何地方使用，那么最好将其保留在对象中
于 2013-07-20T22:30:41.587 回答