在Objective-C中进行属性重写有什么害处？

对于您提到的每种情况，都有一个适当的位置，并且在野外使用的频率也不同。您只需要注意不要踩到自己。我将举例说明我个人遇到的情况。 子类化有意覆盖属性 在这种情况下，就像乔提到的那样，您最好确切地知道自己在做什么，并且在覆盖属性之前没有其他选择。我个人发现，通常只需覆盖已有属性的单个setter或getter即可实现自定义，而不是重新声明和合成该属性。例如，考虑一个专门的UIView子类，该子类仅具有UIClearColor背景才有意义。要强制执行此操作，您可以覆盖“ 0”以仅显示警告消息，然后不调用super的实现。我会说我从来没有理由要完全重写一个属性，但是我不会说它在某些情况下需要完全劫持一个现有属性的情况下不是有用的工具。 私人财产 这比您认为的有用。私有财产的替代方案是普通的ol \'ivar，我们都很熟悉。如果这是一个随频率变化的ivar，则最终将得到如下代码块：

[_myIvar release], _myIvar = nil;

要么：

[_myIvar release];
_myIvar = [someValue retain];

虽然看起来还不错，但是像这样的内存管理样板代码变得非常古老，非常快。或者，我们可以将上面的示例实现为具有保留语义的私有属性。这意味着，无论如何，我们只需要：

self.myIvar = someValue;

一段时间后，这在眼睛和手指上容易得多。您正确地指出，由于此属性对于Universe的其余部分不可见，因此它可能会被子类意外覆盖。在Objective-C中进行开发时，这是固有的风险，但是您可以采取措施使风险逐渐减小。这些措施是可预测地修改私有财产名称的变体。您可以在这里走无限路：举例来说，例如，您将私人财产名称的首字母缩写和下划线添加为个人政策。对我来说，我会得到诸如

mw_ivar

以及相应的corresponding5ѭ和

-mw_ivar

访问器的信息。是的，从统计学上讲，有人可能会偶然出现并意外覆盖该名称，但实际上，他们不会。尤其是如果您可以将自己的实践发布给可能使用您的代码的人。而且，我可以肯定地说，苹果并没有四处走走，也没有制造出以这种方式被破坏的私有财产，因此您在这方面也将很安全。 公开只读，私有读写 这只是标准做法。您是正确的，因为它很有用，而且因为该属性位于标题中，所以它也不危险。任何人无意中推翻它都只能怪自己。     

好问题 以此为您 开发人员应该知道你是什么 在这一点上做，需要添加 对基类的定制 属性。而且既然你知道 你正在做，你会正确地打电话 ѭ7的实现，除非 您有充分的理由不这样做。的 决定不叫超级可能 有害的，尤其是在某些情况下 你不知道那里的基础 类已实现。 是的，这是有害的，但可以 通过不过度使用类别来避免 并仔细选择一个名称 属性或方法并考虑 给它们加前缀。 是的，您是正确的，这对 限制对您财产的访问。 ＃2的示例

@interface UIView(PFXextended)
-(NSArray*)PFXGetSubviewsOfType:(Class)class;
@end