2013-12-12 47 views
1

我有一种情况,我有一个纯粹静态的无状态门面来提供对服务集合的访问。我正在考虑使用NS_ROOT_CLASS作为提供基类的替代方案,因为Facade没有内存管理需求。试想一下:NS_ROOT_CLASS对于IOS开发是否“安全”?

NS_ROOT_CLASS 
@interface UtilityThing 
+ (void) Service1; 
+ (void) Service2; 
@end 

服务1 &客服2有效地代表“单身般的”服务类的实例。所以调用代码如下所示:

[[UtilityThing Service1] thingService1Does];

除了一个事实,即它没有实例数据,我选择了NS_ROOT_CLASS部分简化类的用法,所以,唯一的代码完成建议是相关的人(回复:XCode 5: Is there any way to group/filter/sort what shows up in code-completion?

有谁知道这种模式是否存在可能阻止应用程序通过认证的陷阱?或者如果在使用NS_ROOT_CLASS时还有其他技术上的考虑因素?

+0

这比仅仅定义全局函数'UtilityService1'和'UtilityService2'好吗? –

+0

也许只有一点点,因为用户不需要对所有Utility *进行排序来了解哪些服务可用......尽管像UtilityService *这样的详细约定也可以工作。 –

+0

@robmayoff - 在这种情况下,我希望服务的单例实例彼此了解,而不将底层服务实现为单例。所以门面也为每个服务注入必要的参考。 –

回答

1

一切都好。你被允许创建你自己的根类。如果你不需要创建UtilityThing的实例,它看起来是正确的。

3

是的,你可以做到这一点。

但是不要。

定义一个新的根类 - 即使是一个只包含类方法的新根类 - 都是非常不典型的模式。即几乎从未做过。从来没有做过这样的事情,调试器和/或其他开发工具很可能会把它看作有点奇怪。

只要声明它是NSObject的子类。或者创建一个单例并让它们成为实例方法,因为几乎可以肯定的是,你最终会希望将状态作为你的实用程序的一部分来存储,并且你必须在那个时候重构。

注意:方法应该以小写字母开头。

+1

值得注意的是,将类作为NSObject的子类没有任何开销 - 但是在创建自己的根类时涉及到大量的问题。 – Chuck

+0

我为上面的用例添加了一些更多的上下文。虽然我仍然相信你的答案可能是有道理的,但我在阅读时意识到,我忽略了一些潜在的重要部分。 –

+3

@ J.Paulding代码完成的原因是有效的,但我的经验是,一般来说,这种性质的类方法很快就会因为我提到的有状态原因而重新考虑到实例方法中。但是,就这样说,只要你不试图实例化所说的类*,创建一个根类没有任何问题。系统上的整个框架堆栈预计所有东西都是NSObject的子类(或者非常仔细设计的代理)。 – bbum