AppDelegate属性还是Singleton对象？

Question

这更多是设计最佳实践问题：

[在设计结构时，请说一个基于位置的应用。位置管理器显然是重要的实例，应该易于访问其他对象。

您是否应将其作为appDelegate的属性？还是单身呢？

在哪种情况下，您会优先选择一种？

我知道两者都可以，但是我想确保自己以正确的方式做事，而不仅仅是将所有东西都混在一起。

非常感谢您的投入！

Answer 1

都不是。

在需要时通过自定义init方法或属性传递位置管理器对象。

这将符合SOLID principals S，O和D（单负责，开闭，依赖反转）。

也可以更轻松地进行模拟测试。

Answer 2

IMO最糟糕的选择是将内容存储在应用程序委托中。有关更多信息，请参见What describes the Application Delegate best? How does it fit into the whole concept?。简而言之，应用程序委托是应用程序委托。它不是“全球化事物的应用程序转储场。”

Singletons是通过shared...模式在ObjC中建立已久的方法。经过数十年的流行，并在核心可可框架（NSUserDefaults，NSNotificationCenter，NSApplication，NSFontManager，NSWorkspace，UIDevice等等）中广泛使用，最近年间，人们开始无视于其他技术，尤其是“依赖注入”，这就是说“转让给财产”。

[在ObjC中使用单例多年之后，我开始采用DI思维方式。可测试性方面的改进和依赖性的清晰性非常好。也就是说，有时DI可能会导致尴尬的过渡，尤其是在处理情节提要时。

所以，我会说：

• [如果可行，只需构造对象并将它们分配给需要它们的对象上的属性。
• 如果有很多需要传递的地方，请考虑将它们收集到单个“配置”对象中并传递给它（但这在一定程度上损害了模块化）。
• 如果DI造成混乱（特别是如果它导致将大量对象传递给事物，以便它们可以将对象传递给其他事物），或者如果它强制执行了很多情节提要序列代码，而这些代码本来可以避免的话，在可可中建立了良好且受人尊敬的模式，这没有错。它们是Cocoa Core Competency。
• 如果发现自己正在呼叫(MyAppDelegate *)[[UIApplication sharedApplication] delegate]，则说明您做错了。

Answer 3

使另一个单身人士进行位置管理。 Single responsibility是SOLID的第一原理。

Answer 4

想想您在AppDelegate中真的需要吗？

例如，对于位置管理器，不可以。您最好将位置管理器及其所有相关方法放在单独的类中，以保持@vladimir所说的奇异性原则，并在以后可以重用。

[AppDelegate负责处理应用程序启动和/或进入后台时发生的情况，初始化核心数据，注册推送通知和其他第三方库，例如解析，...

向appDelegate添加其他内容会使它随着时间的推移而变大，并且很难维护。

何时将不属于AppDelegate的内容添加到其中？我认为，当应用程序很小时，您会知道它不会扩展，因此您需要花时间而不是干净的代码。

检查AppDelegate responsibilities以及Matt的此answer

Answer 5

您可以创建CLLocationManager的多个实例，并在需要时使用它们。

如果创建一个实例并尝试共享它，那么您将难以转发委托方法，或者尝试将它们重新实现为导致严重混乱的通知。