单身人士:专业人士，同事，设计人员

Question

我承认。我在用单身汉。我知道你们都会说些什么，坦率地说，在互联网上看到所有这些答案，谈论单身人士的坏处，以及反对他们的建议，真的让我对我的编程实践产生了疑问。

我已经在StackOverflow上读过一些关于单身者的文章，但我发布这个问题不仅是为了问他们，而且是为了了解我在程序中使用他们的方式。

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

因此，让我们考虑一下我经常使用单例的一些情况：

1. 若要创建全局变量的访问器，如根视图控制器、特定且始终存在的视图控制器、应用程序状态、全局托管对象上下文.像这样的东西
2. 创建实用程序类，其任务是处理数据应用程序范围内的数据。例如，我创建一个Singleton来操作我的缓存数据库，它依赖于Core数据。因为我需要在不同的视图中创建缓存和其他东西，所以创建一个类来处理数据库内部/输出(小心线程安全)会感觉更好。
3. 处理网络会话。实际上，我使用它来保持一个连接的活力，并每XX秒向服务器发送类似于PINg的东西。

我想这就是总结。我真的很希望其他开发者在这件事上有意见。

你认为对上述问题有更好的解决办法吗？

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

从多线程的角度来说，忘记单线程会更好吗？

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

Answer 1

单例当然并不总是坏事，但正如您所提到的，您必须小心线程安全(在这个主题上，请查看这个关于单例初始化的博客帖子 )。

单身汉经常被指责为邪恶的原因之一是，如果他们过分依赖于独生子女及其行为，那么他们就很难“扩展”程序的各个部分。您提到了数据库访问，服务器或桌面应用程序可能从单例实现开始处理所有数据库需求，然后尝试使用多个连接来加快独立请求，等等。拆分这样的代码非常困难。

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

如果您向每个视图控制器传递一个对ManagedObjectContext的引用，则可以获得一些灵活性。大多数情况下，您只需将相同的上下文从一个视图控制器传递到下一个视图，但如果将来决定这样做，您可以为编辑视图创建一个新的ManagedObjectContext，在该视图中，您可以使用上下文的撤销功能，但只有当用户决定保存这些更改或很容易地丢弃它们时，才能将更改合并回“根”上下文。或者你想对一组对象做一些背景处理。如果所有内容都在相同的上下文中运行，则最终会出现同步问题。

Answer 2

• 若要创建全局变量的访问器，如根视图控制器、特定且始终存在的视图控制器、应用程序状态、全局托管对象上下文.像这样的东西

单身者是全球性的。用另一个全局包一个全局并不能真正帮助任何事情。

• 创建实用程序类，其任务是处理数据应用程序范围内的数据。例如，我创建一个Singleton来操作我的缓存数据库，它依赖于Core数据。因为我需要在不同的视图中创建缓存和其他东西，所以创建一个类来处理数据库内部/输出(小心线程安全)会感觉更好。

当然，但这可能不需要是单身。事实上，核心数据设计的一部分是，拥有多个与同一存储区对话的MOC是有效的。

• 处理网络会话。实际上，我使用它来保持一个连接的活力，并每XX秒向服务器发送类似于PINg的东西。

如果服务器可能对每个用户的n个连接/IP地址限制，这应该是一个单例。否则，它可能不需要是独生子女。

正如我在我的博客文章中提到的那样，我更喜欢的解决方案是让每个对象都拥有对方的对象。例如，MOC和connection对象都属于任何需要使用它们的对象。这改善了内存和资源管理(单例对象永远不会死)，并使应用程序的总体设计更加简单。