将SOLID应用于UIApplicationDelegate

作为iOS开发人员,您一定熟悉AppDelegate类及其遵循的协议。 那是一切*开始并有时结束的地方。 App委托托管了大量有用的方法和回调。 与您应用的生命周期,后台传输,后台获取或连续性相关的所有内容。 更不用说用户和远程通知了。

确实功能强大,但是……对于一个很小的班级来说,这不是太多吗? 那么单一负责原则呢? 它只有一个改变的理由吗?

当您的应用程序增长时,您会添加更多服务,例如社交登录,分析,崩溃报告。 所有这些好东西都有它们自己的库,当然需要在AppDelegate中进行设置。 这就是您的代表开始看起来和闻起来像一些旧的意大利细面条代码的地步。 对于我的一些旧AppDelegates增长了多少行,我将不为您提供令人尴尬的细节。

不要误会我的意思。 Apple Cocoa上存在的代表模式非常好,而且一定会成功。 但是,这是一对一的关系,显然不适合这种情况。 如何将代表变成更适合这份工作的代表? 这就是我最喜欢的一对多设计模式之一,即观察员。

让我们尝试一下。

将此数组作为实例变量添加到您的AppDelegate。

  私人 var观察者:[UIApplicationDelegate]? 

现在,在需要转发给观察者的每个委托方法中,添加此简单循环。

  func 应用程序_应用程序:UIApplication, 
didFinishLaunchingWithOptions launchOptions:[UIApplicationLaunchOptionsKey:Any]?)->布尔{
观察者?.forEach {
_ = $ 0.application?(应用程序,didFinishLaunchingWithOptions:launchOptions)
}
返回
}

而且…就是这样。 您(可能)永远不会再触摸AppDelegate。

太好了,但是我需要在AppDelegate中设置的新炫酷服务呢?

让我们设置Firebase。

 导入UIKit 
导入Firebase

FirebaseObserver类 :NSObject,UIApplicationDelegate {

func应用程序 (_应用程序:UIApplication,
didFinishLaunchingWithOptions launchOptions:[UIApplicationLaunchOptionsKey:任何]? = nil)->布尔{
FirebaseApp.configure()
返回真
}
}

现在将观察者添加到数组中(您可以使用一些DI框架)

  私人 var观察者:[UIApplicationDelegate]?  = [ 
FirebaseObserver()
]

太好了,现在您的AppDelegate已关闭以进行修改,打开以进行扩展!