如果我想添加类型化属性,子类化 NSNotification 是正确的途径吗?
我正在尝试对 NSNotification
进行子类化。
Apple 的 NSNotification 文档声明如下:
NSNotification
是一个没有实例变量的类簇。像这样, 您必须子类化NSNotification
并重写原始方法名称
、对象
和用户信息
。您可以选择任何指定的初始化程序 你喜欢,但请确保你的初始化程序不会调用NSNotification
的init
实现(通过[super init]
)。NSNotification
并不意味着直接实例化,它的init
方法引发异常。
但这对我来说并不清楚。我应该创建这样的初始化程序吗?
-(id)initWithObject:(id)object
{
return self;
}
I am trying to subclass NSNotification
.
Apple's docs for NSNotification
state the following:
NSNotification
is a class cluster with no instance variables. As such,
you must subclassNSNotification
and override the primitive methodsname
,object
, anduserInfo
. You can choose any designated initializer
you like, but be sure that your initializer does not callNSNotification
’s implementation ofinit
(via[super init]
).NSNotification
is not meant to be instantiated directly, and itsinit
method raises an exception.
But this isn't clear to me. Should I create an initializer like this?
-(id)initWithObject:(id)object
{
return self;
}
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
子类化
NSNotification
是一种非典型操作。我想在过去的几年里我只见过一两次这样的事情。如果您希望将内容与通知一起传递,那么
userInfo
属性就是用于此目的的。如果您不喜欢直接通过userInfo
访问内容,您可以使用类别来简化访问:您还可以使用此方法来简化
NSNotification
创建。例如,您的类别还可以包括:如果出于某种奇怪的原因,您需要属性是可变的,那么您需要使用 关联引用 来实现这一点:
Subclassing
NSNotification
is an atypical operation. I think I've only seen it done once or twice in the past few years.If you're looking to pass things along with the notification, that's what the
userInfo
property is for. If you don't like accessing things through theuserInfo
directly, you could use a category to simplify access:You can also use this approach to simplify
NSNotification
creation. For example, your category could also include:If, for some strange reason, you'd need the properties to be mutable, then you'd need to use associative references to accomplish that:
看来这确实有效。例如:
还要注意与 NSNotifications 相关的大量问题。使用 NSNotification notificationWithName:object: 实现的 NSNotification 类型是 NSConcreteNotification,而不是 NSNotification。更尴尬的是,如果你正在检查类, NSConcreteNotification 是私有的,所以你没有什么可以比较的。
It seems this does work. For example:
also beware a massive Gotcha related to NSNotifications. The type of NSNotifications greated using NSNotification notificationWithName:object: is NSConcreteNotification, not NSNotification. And to make it a little more awkward, if you are checking for class, NSConcreteNotification is private so you have nothing to compare to.
确切地说,您无需设置它 - 您只需重写
name
方法的实现,以便它返回您想要的内容。换句话说:你的初始化器看起来不错——我之前没有见过一个不调用其超类实现的
init
示例,但如果这就是文档所说的你应该做的,那么它可能值得尝试一下。You don’t set it, exactly—you just override the implementation of the
name
method so it returns what you want. In other words:Your initializer looks fine—I haven’t seen an example of an
init
that doesn’t call its superclass’s implementation before, but if that’s what the doc’s saying you should do, it’s probably worth a try.您可以在发送通知时传递
userInfo
参数。为什么不创建一个有效负载并发送它。完毕。
附带说明:多年来,我发现有意识地努力避免子类化使我的代码更加干净、可维护、可更改、可测试和可扩展。如果您可以使用协议或类别来解决问题,那么您就不会将自己锁定在您提出的第一个劣质设计中。结合 Swift 2.0 协议扩展,我们也真的很开心。
You can pass a
userInfo
argument when delivering a notification. Why not create a payload and send that.Done.
As a side note: I've found over the years that making a conscious effort to avoid subclassing has made my code more clean, maintainable, changeable, testable and extensible. If you can solve the problem using protocols or categories then you wont lock yourself into the first shoddy design you come up with. With Swift 2.0 protocol extensions in the mix we're really laughing too.