What's the harm of property override in Objective-C?

Question

There are several situations where you might override a super class's property.

1. 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?

2. 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?

3. 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.

Horseleech

Answer 1

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:

[_myIvar release], _myIvar = nil;

or:

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

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:

self.myIvar = someValue;

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_ivar accessors. 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.

Bengali

Another usecase you're missing in this otherwise great answer is for specifying a more specific type on a subclass. I.e. you have an property of type id on the parent. On the subclass, you can make this more specific by redeclaring the property (such as an NSString*) and then using @dynamic propertyName in the subclass to inform the compiler to use the storage in the parent. – Lam

Answer 2

Good question

1. 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 unless you 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.

2. 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.

3. Yes you are correct that is good for limiting access to your property.

Example for #2

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

Origin