Ios 一个类是否应该保存数据以将其传递给另一个类？

我正在为iOS创建一个登录应用程序，偶然发现了一个设计问题。在我的应用程序中，一些数据（例如，

当前用户id

）必须在视图控制器之间共享，因此我最初的想法是将这些数据保存在

AppDelegate

中，并在需要时从那里调用。这是可行的，但这意味着

AppDelegate

将执行它不打算执行的工作，因此这将是一个糟糕的体系结构，因此我考虑创建一个singleton类来保存所有共享数据。这似乎更为集中，我在以前的一些应用程序中使用了这一策略，但通过谷歌搜索单身人士课程的最佳实践，我发现许多不利于使用它们的结果，因为它们：

隐藏依赖项

违反单一责任原则

使单元测试变得困难

（摘自这个问题的最上面的答案：）

另外两种设计模式的替代方案是在视图控制器之间来回传递数据，但这似乎同样不合适。例如，

当前用户id

我必须将其从登录视图控制器传递到主视图控制器（对于所有用户都是相同的），然后从主视图控制器传递到为用户定制的更为指定的视图控制器。在这种情况下，主视图控制器保存数据只是为了将数据传递给更具体的视图控制器，在我看来，这似乎也违反了单一责任原则。让主视图控制器保存不需要的数据是一种糟糕的设计，还是有更好的替代方案

存储模型视图控制器应用程序的模型状态没有“神奇”的方法：您构建一个类，然后将其“锚定”到某个地方以便于访问

一种常见的做法是使用app委托。它很方便，因为它是一个系统提供的单例，在全球范围内可供您的应用程序使用，但它在逻辑上是次等的，因为正如您所指出的，AppDelegate并不是用于此目的的

另一个常见的策略是使用单例。这在应用程序开发中很常见，在实践中效果很好。您可以通过限制视图控制器的初始设定者访问您的单例来缓解常见的不满-这解决了隐藏的依赖关系和可测试性问题

最后，您可以传递数据，在这种情况下，它与在一个视图控制器中“锚定”数据相同。可以说，这会导致比单例更大的问题，因为依赖关系变得更难跟踪

---

我建议将状态存储在单例中，并在视图控制器的初始化代码中使用它。通过这种方式，对单例的依赖仍然是本地化的，您可以用最少的努力来测试您的逻辑。

许多人确实反对单例，主要是因为它暴露了全局状态，这很容易导致您在代码中没有预料到的问题。不过，我想说，这取决于你的经验水平和应用程序的大小。如果您不太熟悉更高级的设计模式，并且应用程序不打算成为一个长期产品，那么我会说选择单例应用程序是完全好的（还因为您需要理解，当您想要生产更大、可扩展的项目时，为什么它可能不好，并且您可以通过自己体验它的局限性来做到最好）@nburk目前该项目规模不大，但最终可能会如此。你能给我一些更先进的设计模式的例子吗？或者是一些我应该考虑阅读的书。我在这里学习：）这里有一篇关于这个主题的objc.io文章，我发现它对理解单身滥用的好处非常有帮助，请不要误解我，在这种情况下使用单身并不是你可能做出的最糟糕的选择（我知道其他人会不同意这一点）。只需注意可能随之而来的问题。我敢打赌，您在野外找到的大多数生产代码都使用单例存储用户凭据和会话数据，因为这确实是一个方便且近在咫尺的解决方案。使用单例包含全局状态信息（如当前用户ID）是完全有效的，尽管它与使用AppDelegate没有什么区别（其中专门包含全局状态信息）。单例的危险在于用户很容易落入创建新单例（或重载现有单例）的陷阱每次都有一些需要在两个类之间共享数据，即使一些即使是适度谨慎的设计也会允许数据作为参数传递。一旦开始，复杂性会快速增长。