弱“分配”引用而不是单例

Question

我有很多对象引用同一类存储数据。在之前的节目中，我使用过单身人士，但是我试图放弃这种做法，只在必要时将它们作为最后的手段使用，这主要是因为他们声名狼借（事实上我过去曾经滥用过它们）。 / p>

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

@property (nonatomic, assign) MyDataClass*mydata;

在类的自定义init中，我将引用作为方法参数传递，然后property分配给此引用。

这是一种有效，可接受的做事方式吗？在使用单身人士时，我很难找到组织上的优势。

Answer 1

作为一项规则，您应该只对一个单独的类使用对象，在这些对象中存在多个对象是没有意义的。否则，最好避免使用它们，因为它们会引入耦合：每个使用单例的类最终会紧密耦合到单例。

传递对东西的引用很好。当然，除非必要，否则它们不一定是弱引用，以避免保留周期。

如果您确实发现在大量课程中传递相同的对象，您可能需要考虑分担责任并重新构建应用程序。

Answer 2

您使用的模式很好，最终这种模式在所有标准C ++程序中使用，无需引用计数或其他高级内存管理工具。您唯一必须确保您的对象层次结构严格遵守引用的弱点，即具有引用的对象对该引用后面的对象的依赖性。换句话说，您始终必须确保在引用之前删除引用的所有者，并且您必须手动确保，因为您没有使用引用计数。

这对您，程序员来说意味着更多的责任，因为您始终必须完全控制对象的生命周期。由于你不能从具有弱引用的代码中知道原始对象是否仍然存在或者是否被删除，因此很容易弄错你的模式。你必须用你的设计模式来确保这一点。

由于这个原因，我不建议“混合”这两种方法，即对一个对象的弱引用，该对象可能被retain类型属性释放出来（当属性更改来自您的对象），autorelease或ARC。

引入引用计数是为了从程序员那里拿走这个责任，并且更容易编写安全的代码。您的模式很好，它被数以百万计的C ++程序使用，但您必须意识到自己的责任。

Answer 3

保留/分配和使用单身人士不是互斥的模式。我不会对单身人士犹豫不决，起初我开始使用iOS时就是这样。

由于是一个java网络应用程序开发人员，Singletons由于紧密耦合而很糟糕，特别是因为如果你想在负载均衡器/（现在是云）上分发你的应用程序......那么你的单身人士将成为瓶颈 - 并且不易扩展。

使用单身人士进行单元测试时也存在问题，并且在测试期间不得不重置它的状态，或者甚至试图模拟出来。

然而，在Objective-C和iOS开发中 - 我并没有真正看到单身人士的许多缺点。你的应用程序不会被缩放，并且sdk已经充斥着单身来阻碍你的单元测试。