使用预定义的实例

Question

关于实例的一些问题是即使它们包含相同的值，Equals方法也不会提供true。因此，尝试覆盖Equals方法提供的速度比参考相等更慢。

虽然我正在考虑性能问题，但我认为创建2个相同但内存地址不同的实例是愚蠢的。如果我可以避免使用不同的引用创建相同的实例将提高性能并且有助于比较引用将比编写自定义Equal方法更容易。

例如：

我有坐在棋盘坐标上的坐标类。所以我只需要Coordinate[8,8]数组代表所有板的坐标。我可以创建所有实例，而不是创建实例，然后我的工厂方法可以返回它们。

Cooardinate.Get(2,3)代替new Coordinate(2,3) 首先是静态类的静态方法，它返回给定值的预定义坐标。

另一个优点是我们不会花时间在内存中创建和收集垃圾对象。所有这些都已经预定义了。我们还可以方便快捷地为实例提供唯一的GetHashCode，例如0表示[0,0]，1表示[0,1] ....

不值得尝试吗？这个想法会使编码更难写或理解？有没有这样的模式？

嗯，很快这种方式的缺点是什么？

Answer 1

这是一个很好的解决方案，在某些情况下可以节省大量的时间和内存。主要缺点是，如果你的对象是可变的，它会变得非常复杂。如果不是这样的话，那真的不是那么糟糕。您只需确保所有实例都是从同一工厂获得的。您甚至不必提前创建所有实例，但可以在第一次请求特定参数集时使类创建新实例（基本上是延迟加载）。

Answer 2

在这种情况下，你正在处理国际象棋棋盘（总共64个坐标），你不需要过分关注性能或垃圾收集。话虽如此，我认为在字典中保持基线64坐标是很好的（并且有意义）。在Equals（）比较方面，你基本上比较了2个整数值，它们会快速闪烁，所以重写Equals（）方法来指定比较是正确的方法。

Answer 3

简短的回答是，这种方法的缺点在于它增加了代码的复杂性，从而使得编码更加困难，调试更加困难，维护更加困难。

因此，与所有优化一样，如果您真正需要优化（例如运行方式太慢，或使用太多内存），并且奖励（更快的性能，更小的内存使用），您应该只考虑它）超过风险（花时间优化，当你可能做一些更有用的东西，引入一个错误，无法找到错误，未来能够快速，轻松地修改代码，或没有引入错误）

Answer 4

如果由于必须进行深度比较以确定相等性而确实遇到了性能问题，那么您可能需要查看Flyweight pattern，但因为您只谈论64对小插图我认为在这种情况下完全矫枉过正。你真正需要的是覆盖Equals运算符来比较两个坐标 - 这将足够快。任何比这更复杂的事情都可能是错误的优化，至少在大多数普通平台上都是如此。