我对设计模式有点不屑一顾。我刚刚开始使用单例,我正在考虑使用一个方便地将数据存储在一个集中的位置,但在此之前我读了一些似乎在说这不正确的设计的帖子(或者我很困惑) ,但不清楚为什么。我想做的是:
将多个对象数组存储在一个集中的位置,以便可以处理这些对象以保持持久性。
如果不是单身人士有更好的方法吗?如果这是糟糕的设计将是很好的知道为什么。
答案 0 :(得分:4)
单身人士模式的实用性和适用性在很大程度上取决于应用它的环境。
最大的抱怨是基于单例的代码的可测试性。其他投诉包括它可能在并发环境中出现的潜在问题,以及可能面临试图收回单身人士所拥有资源的困难。
但是,这些问题都不是开发iOS应用程序的主要问题:
由于这些考虑因素,单例模式成为iOS应用程序的流行实现技术。只要你知道它的缺点并愿意与它们一起工作,在iOS应用程序中使用单例模式绝对没有错。
答案 1 :(得分:3)
许多单例实现都是美化的全局变量。虽然对于那些没有编写和维护大量代码的人来说,这似乎很好,也很方便,但是使用全局变量存在许多问题 - 许多经验丰富的开发人员和团队都禁止这样做。
...将多个对象数组存储在一个集中的位置,以便可以处理这些对象以保持持久性。
即使是一个全局变量也很痛苦,但是它们的几个数组会产生更大的问题。
问问自己:为什么数组中的所有这些对象都必须始终存在并且程序的任何部分都可以访问?只有部分实现需要显示,而且在某些时候只需要某些部分。为什么这些对象数组总是被分配和激活? 创建模型并传递它们,并在需要时将其保存为ivars。
此外,如果它们是持久的,则无需始终加载它们,因为您只需在需要时只读/写所需的内容。
使用全局变量(单例)只会混淆你的对象依赖图(BAD - 维护噩梦)。
OP中没有证据表明您的案例不典型。虽然现在看起来似乎是一个好主意,但今天的便利通常会在未来花费很多。
关于滥用全局变量和单例及其引入的问题已经写了很多(ObjC单例/全局在这方面与例如C,C ++或Java中的实现没有太大差别)。即使是20年前的文章,仍然会有很好的建议 - 今天这个等式会更加复杂。
答案 2 :(得分:0)
我非常赞同justin,因为这种习惯可以转移到其他语言。我想补充一点,在考虑单身时,问自己一个问题“我的应用程序如何通过只使用这个类的一个实例来获益?”我不是世界上最有经验的程序员,但我还没有找到任何有理由创建一个Singleton。此外,大多数框架已经合理地实现了单例,例如访问文件/目录的单例(例如[NSFileManager defaultManager])。即便如此,Apple建议:
“如果您打算使用文件管理器的委托来接收 关于完成基于文件的操作的通知,您 应该创建一个新的NSFileManager实例(使用init方法) 而不是使用共享对象。“
如果您有任何疑问,该课程应不成为单身人士。