design-patterns - 如何使用代理模式来替换单例？

Question

这是对 what is so bad about singletons 中的一些评论的回应。

有人建议可以使用代理模式而不是单例来缓存数据库数据。但是我看不到优势，实际上单例似乎更“可控”。

让我详细说明这个问题。假设您有一个数据库，其中包含大量数据，并且永远不会更改，因此可以将其视为只读，为什么代理模式比单例模式更好地建模此数据缓存？

(PS:如果您要说“因为它更'可测试'!” - 请详细说明，我仍然习惯这些概念)

谢谢你的帮助!

Answer 1

免责声明:我在这里用 java 术语说话

单例现在被认为是一种反模式，主要是因为最近被滥用了很多，因为它们是一种在应用程序中共享数据的快速方便的方式——这在某种程度上是对设计模式的过度扩展，更适合提供对共享资源的访问控制.

考虑一个程序标准输出:该资源的访问需要由一个访问点来保护，以允许写入同步，这就是为什么您在 java 中拥有例如 System.out 作为静态实例的原因。

问题是，当你开始使用单例时，你需要知道你在做什么的每一个细节，因为你对你的单例类做了很多严格的假设，最重要的是它是唯一的一个系统中的类(class)。然后您开始使用它，假设它始终是您资源的单个入口点，然后出现令人讨厌的错误，因为您的类现在已部署在 ejb 服务器上，并且每个 ejb 上下文都有自己的单例，再加上一个用于每个从服务器重新加载的 jsp，每次你的单例被序列化和反序列化时加上一个单例(因为你可能忘记覆盖 readResolve() 方法)。

所以这就是为什么单例必须非常小心地使用，并且现在被认为是一种反模式，尽管它们对于它们的预期用途完全有用。

在数据库缓存的情况下，让每个需要缓存的类都使用此“缓存”资源的代理是一种更好的方法，因此您可以在代理本身中添加“查找资源”的逻辑将逻辑与缓存单例的检索相关联，这取决于环境可能会或可能不会起作用。

因此，简而言之，使用单例作为对资源的共享访问的手段是不好的，因为您正在硬编码查找资源的方法(并忽略单例陷阱)，同时让单例控制资源以实现同步目的是完全可以接受的。

想想信号量，只有当你总是能得到相同的信号量时，这些才有效。在后一种情况下，问题可能是从您需要访问该信号量的任何地方访问单例:在这里，您需要一些类来包装单例并提供对信号量本身生命周期的更好控制。

代理旨在涵盖“跨系统提供资源”的角色，无论是单个应用程序、客户端服务器系统、同一系统的不同组件等等，还有一个额外的好处是使用 èrpxy 的检索方法资源是不透明的。您可以让他们为您提供一个包含缓存值的哈希图的单例，您可以让他们访问网络上的某个 memcached somwhere，您可以让他们在测试期间读取 csv，所有这些都不会改变您从应用程序调用它们的方式。