Objective-C 中的属性覆盖有何危害？
在多种情况下，您可能会覆盖超类的属性。
您声明一个与其属性具有相同名称和相同属性的属性 超类'。（因为如果你改变 属性你可以获得编译器 警告）。你可以综合 使用您创建的 ivar。什么是 这个的用途？或者有什么坏处 它能做什么？
如果超类在类扩展（类别 没有名字），那么它可能不是 在头文件中。如果你不这样做 从标题中知道该属性 文件，可以声明相同的名称 具有任何属性或属性的财产 你想要的课程。但是 setter/getter 方法将被覆盖 那些“秘密财产”的。 我认为这只会造成伤害。但 因为你从标题中不知道 文件，如何避免这种情况？
您可以在头文件中将属性声明为“只读”，并在 类扩展将其重新声明为 “读写”。我认为这就是 在
我对这些情况的理解正确吗？而且我不知道第一种和第二种情况能有什么好处。但如果我想避免第一种情况，我可以在声明之前检查子类是否已经拥有该属性。但如果该属性不在公共头文件中，如第二种情况，我只是不知道该怎么办。
There are several situations where you might override a super class's property.
You declare a property with the same name and same attribute of its
superclass'.(since if you change the
attribute you can get an compiler
warning).And you can synthesieze
with an ivar that you create. What's
the use of this? Or what's the harm
can it do?If a superclass declares a property in a class extension (a category
with no name), then it might not be
in the header file. If you don't
know that property from the header
file, you can declare the same name
property with what ever attribute or
class you want. But the
setter/getter method will override
the ones for that "secret property".
I think this can only do harm. But
since you don't know from the header
file, how can you avoid this?You can declare a property in the header file as "readonly" and in
class extension redeclare it as
"readwrite". I think this is the
situation that it can do good.
Is my understanding about these situations right? And I don't know what good the first and second situations can do. But if I want to avoid the first situation, I can check if the subclass already has the property before I declare it. But if the property is not in the public header file, as in the second situation, I just don't know what to do.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您提到的每种情况都有一个合适的地方，在野外使用的频率也不同。您只需小心不要踩到自己即可。我将用我个人遇到的例子来说明。
子类化以有意覆盖属性
在这种情况下，就像乔提到的那样，在覆盖属性之前，您最好确切地知道自己在做什么，并且没有其他选择。我个人发现，通常足以覆盖现有属性的单个 setter 或 getter 来实现自定义，而不是重新声明和合成属性。例如，考虑一个专门的 UIView 子类，它只有具有 UIClearColor 背景才有意义。要强制执行此操作，您可以重写
-setBackgroundColor:以仅打印警告消息，然后不调用 super 的实现。我会说我从来没有理由完全覆盖一个属性，但我不会说在某些需要完全劫持现有属性的情况下它不是一个有用的工具。私有财产
这比您想象的更有用。私有财产的替代方案是我们都熟悉的普通 ol' ivar。如果这是一个以一定频率变化的 ivar，您最终会得到如下所示的代码块：
或：
虽然它看起来还不错，但像这样的内存管理样板代码变得非常旧，非常快。或者，我们可以将上面的示例实现为具有保留语义的私有属性。这意味着，无论如何，我们只需要：
一段时间后，这对眼睛和手指来说会容易得多。您正确地注意到，由于此属性对于宇宙的其他部分是不可见的，因此它可能会意外地被子类覆盖。这是在 Objective-C 中开发时固有的风险，但您可以采取措施使风险变得很小。这些措施是以可预测的方式修改私有财产名称的变体。您可以在这里走无数条路：比方说，您制定了一项个人政策，即在您的私有财产名称前添加您的姓名首字母和下划线。对我来说，我会得到类似
mw_ivar的东西，以及相应的-setMW_ivar:和-mw_ivar访问器。是的，从统计上看，有人可能会意外地覆盖该名称，但实际上，他们不会。特别是如果您有办法将您的实践发布给可能使用您的代码的人。而且，我可以有把握地说，苹果公司并没有以这种方式制造私有财产，所以你在这方面也是安全的。公开只读，私有读写
这只是标准做法。你是对的，它很有用，而且也不危险，因为该属性位于标头中。任何不小心超越它的人都只能怪自己。
There is a proper place for each of the situations you have mentioned, with varying frequency of use out in the wild. You just have to use care not to step on yourself. I'll illustrate with example's I have personally come across.
Subclassing to intentionally override a property
In this situation, like Joe mentioned, you had better know exactly what you're doing and have no other options before you override a property. I've personally found it's usually sufficient to override a single setter or getter for an already existing property to achieve customization, rather than re-declare and synthesize the property. For example, consider a specialized UIView subclass that only makes sense to have a UIClearColor background. To enforce this, you may override
-setBackgroundColor:to just print a warning message and then not call super's implementation. I'll say I've never had a reason to completely override a property, but I won't say it couldn't be a useful tool in some case where you need to completely hijack an existing property.Private Property
This is more useful than you give it credit for. The alternative to a private property is a plain ol' ivar, which we're all familiar with. If this is an ivar that's changing with some frequency, you'll end up with chunks of code that look like this:
or:
While it doesn't look too bad, memory management boilerplate code like this gets really old, really fast. Alternatively, we could implement the above example as a private property, with retain semantics. This means, no matter what, we just have to:
Which is much easier on the eyes and fingers after awhile. You're correct in noting that, since this property is invisible to the rest of the universe, it could accidentally be overridden by a subclass. This is an inherent risk when developing in Objective-C, but you can take measures to make the risk vanishingly small. These measures are variations on modifying the name of your private properties in a predictable manner. There are infinite roads you could take here: say, for example, you make it a personal policy to prepend your private property names with your initials and an underscore. For me, I would get something like
mw_ivar, and corresponding-setMW_ivar:and-mw_ivaraccessors. Yes, it's is statistically possible that someone could come along and accidentally override that name, but really, they won't. Especially if you have a way of publishing your practices to those who may use your code. And, I can safely say that Apple has not gone around and made private properties that were mangled in such a way, so you'll be safe on that front as well.Publicly Readonly, Privately Readwrite
This is just standard practice. You're right that it's useful, and also that it's not dangerous since the property is in the header. Anyone accidentally overriding it has only themselves to blame.
好问题
这个的用途是你作为
开发者应该知道你是什么
此时正在做并且需要添加
对基类的定制
财产。既然你知道什么
你正在做的你会正确地打电话
super的实现除非你有充分的理由不这样做。这
决定不打电话超级可以
有害，尤其是在某些情况下
你不知道那里的基地如何
类已实现。
是的，这很有害，但可能会
通过不过度使用类别来避免
并仔细选择一个名字
属性或方法并考虑
给它们添加前缀。
是的，你是对的，这对
限制对您财产的访问。
#2 的示例
Good question
The use of this is you as the
developer should know what you are
doing at this point and need to add
customizations to the base class
property. And since you know what
you are doing you will properly call
the
supers implementation unlessyou have good reason not to. The
decision not call super could be
harmful especially in situations
where you do not know how the base
class is implemented.
Yes this is harmful but can be
avoided by not over using categories
and carefully choosing a name of
properties or methods and consider
prefixing them.
Yes you are correct that is good for
limiting access to your property.
Example for #2