单身人士：优点，缺点，设计顾虑

Question

我承认这一点。我正在使用单身人士。我知道你可能会说什么，坦率地说，在互联网上看到所有这些答案，谈论单身人士的不良方面，并建议不要他们真的让我质疑我的编程习惯。

我已经阅读了StackOverflow中关于Singletons的一些文章，但是我发布这个问题不仅要询问他们，还要了解我在我的程序中使用它们的一些见解。

我觉得我必须在这里澄清一些事情，并询问前方。

所以，让我们考虑某些情况下，我使用的单身很多：

1. 要创建存取全局变量，就像我的根视图控制器，具体和始终存在的视图控制器，应用程序的状态，我的全球管理对象上下文...这样的东西
2. 创建实用类，其任务是处理整个应用程序的数据。例如，我创建了一个单例，它将操作依赖于Core Data的缓存数据库。因为我需要创建缓存和其他东西以便在不同视图中放入数据库中，所以最好创建一个能够处理数据库输入/输出的类（注意线程安全性）。
3. 处理网络会话。实际上，我使用它来保持连接并每隔XX秒将类似PINg的内容发送到服务器。

我认为，总结一下。我真的很希望其他开发者对此事提出意见。

您是否认为上述问题有更好的解决方案？

你认为总有更好的选择单身人士，他们应该避免？

多线程忘记单身是否更好？

任何建议和想法将是有用的，也是最受欢迎的。

Answer 1

单身并不总是邪恶的，但正如你所说，你必须小心线程安全性（关于该主题，请查看blog post关于单例初始化）。

单身人士经常被谴责为邪恶的一个原因是，如果他们过分依赖单身人士及其行为，他们可能会使得难以“规模化”程序的某些部分。您提到数据库访问，服务器或桌面应用程序可能会从单例实现开始处理所有数据库需求，然后尝试使用多个连接来加速独立请求等。分解此类代码可能非常困难。

即使在使用CoreData的iOS应用程序中，不依赖应用程序委托或某个根视图控制器上的全局ManagedObjectContext也会很有用。

如果你通过每个视图控制器引用一个ManagedObjectContext，你可以获得一些灵活性。大多数情况下，您只需将相同的上下文从一个视图控制器传递到下一个视图控制器，但是如果您决定在未来，则可以为编辑视图创建一个新的ManagedObjectContext，您可以使用撤消功能上下文，但只有在用户决定保存它们或容易丢弃它们时才将这些更改合并回“根”上下文中。或者也许你想对整个对象做一些后台处理。如果一切都在同一个环境下运行，那么最终会出现同步问题。

Answer 2

• 要创建存取全局变量，就像我的根视图控制器，具体和始终存在的视图控制器，应用程序的状态，我的全球管理对象范围内......这样的东西

Singletons are globals.用另一个全球包装一个全球并不能真正帮助任何东西。

• 要创建的实用工具类，他们的工作是处理数据的应用范围。例如，我创建了一个单例，它将操作依赖于Core Data的缓存数据库。因为我需要创建缓存和其他东西以便在不同视图中放入数据库中，所以最好创建一个能够处理数据库输入/输出的类（注意线程安全性）。

当然，但这可能不需要是一个单身人士。事实上，核心数据设计的一部分是，有多个MOC与同一商店交谈是有效的。

• 处理网络会话。实际上，我使用它来保持连接并每隔XX秒将类似PINg的内容发送到服务器。

这应该是一个单身，如果服务器可能会执行一些正连接每用户/ IP地址限制。否则，它可能不需要是单身人士。

正如我在我上述的博客文章中提到的，我更喜欢的解决方案是让每个对象拥有其他每个对象。例如，您的MOC和连接对象将分别由任何需要使用它们的对象所拥有。这改进了内存和资源管理（单例对象永远不会死亡），并使应用程序的整体设计更直接。