为什么使用应用程序委托的属性？

我审计有一个appDelegate性能在许多视图控制器的一些代码。为什么使用应用程序委托的属性？

@property (nonatomic, unsafe_unretained) TheAppDelegate *appDelegate;

撇开这种耦合的设计的影响，是否有任何益处，比便利其它，一个appDelegate属性的与检索应用程序委托：

TheAppDelegate *appDelegate = (TheAppDelegate *)[[UIApplication sharedApplication] delegate]; 
[appDelegate someMethod];

来源

2013-04-23 Jason McCreary

这是都非常主观的，所以我给你我的观点：AppDelegate中的任何类用途或功能不缩小系统和应用程序是一个代码味道。有一个属性引用它是双重的。我觉得获得它的丑陋方式本身就是一种沮丧（就像C++中的各种投射方法一样）。在这两种情况下都没有任何好处（一种是强制你记住设置或定义一个属性，另一个强制冗长）。 – CodaFi 2013-04-23 19:11:25

@CodaFi，有没有办法缩小这个问题，所以它不是*非常主观*？我主要好奇的是，如果我*必须*使用这样的代码，我的财产更好。 – 2013-04-23 19:14:56

这是一个主观因素，它是一个编码风格的问题，而不是一个关于具体数字的问题。您可能会收到的唯一答案是意见和经验。我可以给你一百万个案例，我曾经在某些案例中亲自使用过一个或另一个案例，但这绝不会构成权威性的答案。 – CodaFi 2013-04-23 19:18:28

我有时也这样做，即。声明可以使用单例访问方法获取的依赖属性：

@class Foo : NSObject 
@property(strong) NSNotificationCenter *notificationCenter; 
@end 

@implementation Foo 

- (id) init 
{ 
    self = [super init]; 
    [self setNotificationCenter:[NSNotificationCenter defaultCenter]]; 
    return self; 
} 

@end

优点是您可以获得松散的依赖关系。例如，您可以轻松提供自己的模拟实例。在某些情况下，它还会缩短代码，编写_notificationCenter而不是[NSNotificationCenter defaultCenter]。

而第三个原因，我能想到的是，声明特性使依赖明确的：你通过查看对象的状态或行为取决于应用程序的委托公共API知道。在类实现中使用单例完全隐藏了这个事实。

但如果有在您的应用程序多台控制器依赖于应用程序的委托，它可能只是一个设计缺陷。

来源

2013-04-23 19:13:28 zoul

对一般财产有意义。但是，我什么时候会嘲笑'appDelegate'？ – 2013-04-23 19:17:54

也许测试应用程序代表发布的一些通知？只是猜测。无论如何，在您的应用程序中很有可能这个属性真的没有意义。 – zoul 2013-04-23 19:21:37

@JasonMcCreary：一个明显的答案是单元测试你的类与应用程序委托的交互（例如它在特定时间向委托发送某些消息）。 – Chuck 2013-04-23 19:43:26

要回答这个问题的框架。

具体优惠如下： -

简洁的代码 - 该属性设置一次（而且只能读）。如果您多次使用它

self.appDelegate比每次从共享应用程序中获取appDelegate都要简单。（和简单越好）

有可能是轻微的效率优势（虽然这肯定是不成熟的优化和可能不存在依赖于编译器）。

我不得不同意CodaFi它有点臭，所以有创造一些语法糖隐藏一些复杂性的中间地带。

@class MyAppDelegate; 
@interface MySharedAppDelegate : NSObject 

+ (MyAppDelegate*) appDelegate; 
@end 

#include "MyAppDelegate.h" 
@implementation MySharedAppDelegate 

+ (MyAppDelegate*) appDelegate { 
    return (MyAppDelegate*)[UIApplication sharedApplication].appDelegate; 
} 
@end

来源

2013-04-23 19:30:43

我更喜欢使用宏，而不是在每一个viewcontrollers定义一个属性像

#define appDelegate ((MYAppDelegate *)[[UIApplication sharedApplication] delegate])

在constants.h定义这个，它包括在.PCH文件中的标题，我可以有这个appDelegate在我的代码中的任何类。

来源

2013-04-23 19:47:43

不知道在我的代码中到处都有'appDelegate'，但是不错的选择。 – 2013-04-23 19:52:51

只是意味着在项目中的任何类:) – 2013-04-23 20:01:49

我喜欢做这样的：

//in .pch file 
#import "Includes.h" 

//in Includes.h 
#import "AppDelegate.h" 
#define APPDELEGATE() (AppDelegate *)[[UIApplication sharedApplication]delegate]

然后无论我需要问的appDelegate东西，我只是说

[APPDELEGATE() someMethod];

具有的AppDelegate属性其他地方似乎是一个坏主意。不能说为什么，除了已经有一个简单的方法来获得该参考（sharedApplication）。

在这种情况下，它可能只是为了方便开发者。我不得不说，“需要”对AppDelegate的引用无处不在，可能更像是意大利面条代码和糟糕封装的指标。 *顺便说一句，我在appDelegate中存储对一些“全局”变量的引用，这也可能是不良封装的一个指示器......这就是为什么我首先使用APPDELEGATE（）声明的原因; ）

**像NSDateFormatter这样的事情，你会经常需要，但不一定在一个类中“活”，（你不需要每个实例都有一个，但可以应用于多个实例）或引用一些特定的状态，如“全球应用字号”

来源

2013-04-23 20:32:07 Justin

我不认为这是主观的。现在的问题是：

有什么好处，比其他方便的，一个的appDelegate 财产与检索应用程序的委托

而且我认为答案是“不”。除了方便之外，没有任何好处。

理想情况下，你有你的应用程序委托和视图控制器，因此该方法与使用应该没有太大的问题，任何（或最少）的耦合。在我现在正在开发的项目中，我只是在需要时检索委托（在整个代码库中只有2个位置）。如果你在几十个地方这样做，也许将它作为一个属性更有意义，但同样，这纯粹是为了方便。

来源

2013-04-23 21:19:19 zpasternack

为什么使用应用程序委托的属性？

回答

相关问题