我承认了。我正在使用单身人士。我知道你们可能会说些什么，坦率地说，在互联网上看到所有这些答案，谈论单身人士的坏方面，并建议反对他们真的让我质疑我的编程实践。
我已经阅读了StackOverflow中关于Singletons的一些帖子，但我发布这个问题不仅是为了询问他们，而是为了看看我在我的程序中使用它们的方式的一些见解。
我觉得我必须在这里澄清一些事情并向前方指出。
因此，让我们考虑一下我使用单身人士的一些案例：
我认为总结一下。我真的很想得到其他开发者的意见。
您认为上述问题有更好的解决方案吗？
你认为单身人士总有更好的选择，应该避免吗？
在多线程方面忘记单身人士会更好吗？
任何建议和想法都会很有用，也非常受欢迎。
答案 0 :(得分：4)
单身人士肯定不总是邪恶，但正如你所提到的，你必须小心线程安全（关于那个话题，请查看关于单例初始化的blog post）。
单身人士经常被谴责为邪恶的一个原因是，如果他们过分依赖单身人士及其行为，他们可能会更难“扩大”程序的某些部分。您提到数据库访问，服务器或桌面应用程序可能从单件实现开始，以处理所有数据库需求，然后尝试使用多个连接来加速独立请求等。分解这些代码可能非常困难。
即使在使用CoreData的iOS应用程序中，不依赖于应用程序委托或某个根视图控制器上的全局ManagedObjectContext也很有用。
如果为每个视图控制器传递对ManagedObjectContext的引用，则可以获得一些灵活性。大多数情况下，您只需将相同的上下文从一个视图控制器传递到下一个视图控制器，但如果您将来决定，可以为编辑视图创建一个新的ManagedObjectContext，您可以在其中使用上下文但是只有当用户决定保存它们时才将更改合并回“根”上下文，否则就会轻易丢弃它们。或者您可能希望对整组对象进行一些后台处理。如果一切都在相同的上下文中运行，那么最终会出现同步问题。
答案 1 :(得分：1)
- 创建全局变量的访问器，例如我的根视图控制器，特定的和始终存在的视图控制器，应用程序状态，我的全局托管对象上下文......这样的东西
Singletons are globals.用另一个全局包装全局并没有任何帮助。
- 创建实用程序类，其作用是在应用程序范围内处理数据。例如，我创建了一个Singleton，它将运行我的缓存数据库，该数据库依赖于Core Data。由于我需要在不同的视图中创建缓存和其他东西放在数据库中，因此创建一个可以处理数据库输入/输出的类（注意线程安全性）会更好。
当然，但这可能不需要是单身人士。实际上，Core Data的部分设计是让多个MOC与同一个商店通信是有效的。
- 处理网络会话。实际上，我用它来保持连接并每隔XX秒向服务器发送一个类似PINg的内容。
如果服务器可能强制执行某些n-connections-per-user / IP-address限制，那么这应该是单例。否则，它可能不需要是单身人士。
正如我在上一篇博客文章中提到的，我更喜欢的解决方案是让每个对象拥有彼此的对象。例如，您的MOC和连接对象将分别由需要使用它们的任何对象拥有。这改善了内存和资源管理（单例对象永不死亡），使应用程序的整体设计更加直接。