2012-03-30 54 views
0

我有很多对象引用相同类的存储数据。在之前的计划中,我使用过单身人士,但我试图放弃这种做法,必要时仅将它们用作最后​​的手段,主要是因为他们的声誉不好(而且事实上我过去曾滥用过)。弱“分配”引用而不是单例

但我想知道我的新技术有多大优势。我只是创建对同一组数据的弱引用,所以一堆类指向相同的内存来根据需要提取数据。如:

@property (nonatomic, assign) MyDataClass*mydata;

在类的自定义init,我通过参考作为方法参数,则property分配给此引用。

这是一种有效的,可以接受的方式来做事吗?我在使用单例做这件事时很难找到很大的组织优势。

+0

为什么这个“分配”而不是“保留”? – Chuck 2012-03-30 08:11:27

+0

,因为它是一个弱引用,并且该类不拥有该对象 – johnbakers 2012-03-30 08:18:30

回答

0

您所使用的模式就好了,最终这个模式在所有标准C++程序中使用,而不引用计数或其他先进的内存管理工具。您必须确保您的对象层次结构严格遵守引用的弱点,即具有对该引用后面的对象的引用的对象的依赖关系。换句话说,您必须确保引用的所有者在之前被删除,并且必须手动确保,因为您没有使用引用计数。

这意味着你更多的责任,因为你总是必须有在你的对象的生命周期完全控制程序员。由于您无法从具有弱引用的代码中知道原始对象是否仍然存在或它是否被删除,因此很容易让您的模式出错。你必须确保你的设计模式。

由于这个原因,我不建议“混合”这两种方法,即对可能通过retain类型属性(当属性的值从您的对象),autoreleaseARC

引用计数引入夺去程序员这个责任,并使其更容易编写安全的代码。你的模式很好,它被数以百万计的C++程序使用,但你必须意识到自己的责任。

0

作为一项规则,您应该只对单个类使用单个类,而这些单元对于其中多于一个的单元存在是没有意义的。否则,最好避免它们,因为它们引入了耦合:每个使用单例的类最终都紧密地耦合到单例。

通过引用的东西很好。当然,除非必要,否则它们不必是弱的参考,以避免保留周期。

如果你确实发现你在大量的类之间传递相同的对象,你可能要考虑考虑分工和重构你的应用程序。

0

保留/分配和使用单例不是互斥模式。我不会对这个单身人士犹豫不决,我刚开始时就开始使用iOS。

由于是一名java web应用程序开发人员,Singletons由于紧密的耦合而不好,尤其是因为如果您想要通过负载平衡器/(现在的云)分布您的应用程序......那么您的单例将成为瓶颈 - 并且不容易扩展。

Singleton单元测试也存在问题,在测试过程中不得不重置它的状态,甚至试图嘲笑它。然而,在Objective-C和iOS开发中 - 我并没有真正看到单身人士的许多缺点。你的应用程序不会被缩放,并且sdk已经被单身人士遗弃,以阻碍你的单元测试。