ios - 数据访问器对象单例或其他模式？ ( objective-c )

Question

这里好像满足三个要求:On Design Patterns: When to use the Singleton?

我需要它只存在一次。我需要从整个源库访问它。它处理并发访问，即写入锁定，但可以处理并发读取。

大家好，

我一直在阅读很多毫无疑问受过良好教育和睿智的宝贵建议，认为单例是“邪恶的”，单例是反模式或仅仅是坏消息。

关于日志记录有意义但没有其他意义的论点。

只是想知道本质上持久数据存储上下文的情况对于单例是否有意义，即从磁盘读取/写入内存并引用对象图。

如果不是，人们通常如何解决这个问题，我目前对此没有任何问题，我知道它只创建一次，速度很快，访问器逻辑在一个地方。这意味着我只需要一行代码就可以完成任何与数据模型相关的事情。

这留下了唯一的争论，即它不利于测试，因为它是数据的硬编码生产实现，但我不能只写一个方法 swizzle 通过类别或在测试代码中创建测试版本的单例？

来自 DI 测试人员的最后一个论点是，它是一个硬编码实现，而不仅仅是某个东西的接口(interface)，我确实得到了，但我并没有真正使用 DI 框架的主要动力，因为我可以使用协议(protocol)来实现，并使用单独的初始化方法来设置测试中的对象状态。单例只会有两种类型的状态，或者实际上是一种类型……生产。

让它(在我看来)更容易阅读和更快地开发。

改变我的看法吗？

Answer 1

是的，因为有些单例是邪恶的。对于 MRC 知识很少但 ARC 知识较多的新开发人员来说，这听起来很可怕，因为他们需要处理内存、volatile、同步等。

但是并不反对使用它们，它们确实有自己的用途，下面列出了一些。

• 当在多个屏幕 (VC) 之间共享数组和字典等大型数据模型时，我们不能更喜欢将它们存储在 UserDefaults 中(因为 userdefaults 是永久性存储并且存储如此大的条目会使应用程序延迟启动)而不是单例最好，因为它们只保留当前应用上下文，重新启动应用会创建新上下文。

• 当我们需要一个稳定的数据库连接以便在整个应用程序中都可以访问，而不会在每个业务类中搞砸连接和关闭时，我们可以实现它。

• 当我们想要应用程序动态地进行主题化时，我们需要创建一个单例类来保存所有颜色、图像实例等，并在应用程序 VC/Views 等中使用该实例，这样就没有代码重复和重新处理主题发生在所有地方。

你不必改变你的观点，但稍微调整一下以获得对单例的一些积极意图。

希望这能解决问题，谢谢