swift - 模式 : Singletons vs. 静态变量和方法方法

Question

我阅读了很多关于单例模式的资料。我目前正在使用它在我的第一个应用程序中存储全局状态组。我已经到了想知道用哪种方法来实现 API 客户端类和类似方法的地步。

具有静态变量 和静态函数 的结构是否存在相同的问题？

为了说明我的意思，我尝试编写了两次相同的高度简化和完全相同(？)的场景。

<强>1。 View Controller 正在使用的单例:

struct APIClientSingletonClass {

    static let shared = APIClientSingletonClass()

    var stateOfSomehting: Bool = true
    var stateOfSomehtingMore: Bool = false
    var stateNumber: CGFloat = 1234
    var stateOfSomehtingComputed: CGFloat {
        return stateNumber * 10
    }

    func convertSomethingToSomethingElse() {
        // calling method in self like this:
        otherMethod()
    }
    func otherMethod() {
        // doing stuff here
    }
}



// Calling APIClient from outside:
class ViewControllerTalkingToSingleton: UIViewController {

    var api = APIClientSingletonClass.shared

    override func viewDidLoad() {
        super.viewDidLoad()
        api.convertSomethingToSomethingElse()
        api.stateOfSomehting = false
    }
}

<强>2。另一种方法:

struct APIClientStruct {

    static var stateOfSomehting: Bool = true
    static var stateOfSomehtingMore: Bool = false
    static var stateNumber: CGFloat = 1234
    static var stateOfSomehtingComputed: CGFloat {
        return stateNumber * 10
    }

    static func convertSomethingToSomethingElse() {
        // calling method in self like this:
        APIClientStruct.otherMethod()
    }

    static func otherMethod() {
        // doing stuff here
    }
}


// Calling APIClient from outside:
class ViewControllerTalkingToStruct: UIViewController {

    override func viewDidLoad() {
        super.viewDidLoad()
        APIClientStruct.convertSomethingToSomethingElse()
        APIClientStruct.stateOfSomehting = false
    }
}

大家怎么看？方法 2 是否落入了似乎使单例成为一把双刃剑的陷阱？

非常感谢任何输入!柏林最佳

编辑:这个话题很有趣，但我不确定它是否真的与我的问题有关:

Difference between static class and singleton pattern?

鉴于这个话题有很多观点，我来说明一下:我的方法 2 在测试和代码可维护性方面是否具有相同的问题含义？

Answer 1

如果您为测试适应依赖注入(inject)，则基于类的单例是可行的方法。实现此目的的方法是为您的应用程序创建一个单例，例如称为 DependencyManager。在您的 AppDelegate 中(或者如果需要的话，从其他类)，您可以创建任何您想要卡在 DependencyManager 上的 Controller 、网络服务、领域模型等，然后将它们分配给 DependencyManager。您的单元测试将跳过此代码。

然后，您的单元测试可以访问 DependencyManager(并因此在首次访问期间实例化 DependencyManager)，并使用这些 Controller 和服务的模拟版本填充它，以达到每个单元测试所需的任何程度。

您的 UIViewControllers、您的 MVVM View 模型等...可以作为单例访问 DependencyManager，从而获得真正的 Controller 和服务，或者它们的模拟版本，具体取决于您运行的是应用程序还是单元测试。

如果您正在执行 MVVM，我还建议当 UIViewController 将要创建其 View 模型类时，它首先检查 DependencyManager 中的一个特殊属性以查看是否存在 mockViewModel。单个属性可以满足此目的，因为一次只会测试您的 UIViewController 中的一个。它会使用该属性而不是为自己创建一个新的 View 模型。这样，您可以在测试每个 UIViewController 时模拟您的 View 模型。 (能够支持单个 UIViewController 进行测试还涉及其他技巧，但我不会在这里介绍)。

请注意，以上所有内容都可以很好地与还想使用 Storyboard 和/或 Nib 的应用程序一起使用。人们对 Storyboard如此失望，因为他们无法弄清楚如何为他们的 View Controller 进行模拟服务的依赖注入(inject)。嗯，以上就是解决方法!只需确保在您的 AppDelegate 中在设置 DependencyManager 后加载 Storyboard。 (从您的 info.plist 中删除 Storyboard名称，并在 AppDelegate 中自行实例化它)。

我已经用这种方式编写了一些已发布的应用程序，以及一些用于 SDK 的示例应用程序以及测试。我强烈推荐这种方法!并确保在每个此类的开发期间或至少在开发之后立即编写您的单元测试和 viewController 测试，否则您将永远无暇顾及它们!