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