NS_ROOT_CLASS對於IOS開發是否「安全」？

我有一種情況，我有一個純粹靜態的無狀態門面來提供對服務集合的訪問。我正在考慮使用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時還有其他技術上的考慮因素？

來源

2013-12-12 J. Paulding

這比僅僅定義全局函數'UtilityService1'和'UtilityService2'好嗎？ –

也許只有一點點，因爲用戶不需要對所有Utility *進行排序來了解哪些服務可用......儘管像UtilityService *這樣的詳細約定也可以工作。 –

@robmayoff - 在這種情況下，我希望服務的單例實例彼此瞭解，而不將底層服務實現爲單例。所以門面也爲每個服務注入必要的參考。 –

一切都好。你被允許創建你自己的根類。如果你不需要創建UtilityThing的實例，它看起來是正確的。

來源

2013-12-12 15:24:30

是的，你可以做到這一點。

但是不要。

定義一個新的根類 - 即使是一個只包含類方法的新根類 - 都是非常不典型的模式。即幾乎從未做過。從來沒有做過這樣的事情，調試器和/或其他開發工具很可能會把它看作有點奇怪。

只要聲明它是NSObject的子類。或者創建一個單例並讓它們成爲實例方法，因爲幾乎可以肯定的是，你最終會希望將狀態作爲你的實用程序的一部分來存儲，並且你必須在那個時候重構。

注意：方法應該以小寫字母開頭。

來源

2013-12-12 18:30:38 bbum

值得注意的是，將類作爲NSObject的子類沒有任何開銷 - 但是在創建自己的根類時涉及到大量的問題。 – Chuck

我爲上面的用例添加了一些更多的上下文。雖然我仍然相信你的答案可能是有道理的，但我在閱讀時意識到，我忽略了一些潛在的重要部分。 –

@ J.Paulding代碼完成的原因是有效的，但我的經驗是，一般來說，這種性質的類方法很快就會因爲我提到的有狀態原因而重新考慮到實例方法中。但是，就這樣說，只要你不試圖實例化所說的類*，創建一個根類沒有任何問題。系統上的整個框架堆棧預計所有東西都是NSObject的子類（或者非常仔細設計的代理）。 – bbum

NS_ROOT_CLASS對於IOS開發是否「安全」？

回答

相關問題