Apple's doc mentions two ways to create private variables, namely property and ivar, but it does not say which is the preferred way. Which one is Apple's recommended approach or are they equally good in Apple's view?
#interface MyClass ()
#property (nonatomic, strong) NSObject *prop;
#end
or
#implementation MyClass {
NSObject *_prop;
}
Note - I am not asking for personal opinion, but Apple's recommendation. There are similar discussion on this but most have been viewed from personal opinion with no clarification on why one is better than the other and which way Apple advocates (though 99% of Apple sample code uses property)
You should always use #properties because they are safer (e.g. they contain the thread-safe access protection for atomic properties, etc).
And you should also always access properties via their getter/setter instead of directly accessing the instance variables (except in init methods).
As for Apple's recommendations:
Apple engineers answered that at some talks during past WWDC. Sorry no written reference, but I can confirm that they recommend properties over instance variables
In Apple's "Programming With Objective-C" Programming Guide, they mention that you should always prefer using properties over instance variables:
Although it’s best practice for an object to access its own properties using accessor methods or dot syntax, it’s possible to access the instance variable directly from any of the instance methods in a class implementation.
[...]
In general, you should use accessor methods or dot syntax for property access even if you’re accessing an object’s properties from within its own implementation, in which case you should use self
[...]
The exception to this rule is when writing initialization, deallocation or custom accessor methods
Actually in such Programming Guides, like here where they describe the anatomy of an ObjC class, they never mention instance variables and explain how to create them, they only explain properties, so that's a pretty strong indicator that they try to enforce them anyway.
Related
With the current version of Objective-C, what are the official standards and best practices for declaring ivars, using #property and #synthesize? There are a lot of posts and resources on the topic but most of them are fairly antiquated from a year or two ago. I recently learned to only declare ivars in a statement block in the implementation of a class so that the encapsulation principles of OOP aren't broken but is declaring ivars even necessary in this day and age? What would be a possible use case where doing:
#interface MyClass()
#property (nonatomic) NSString* data;
#end
#implementation MyClass{
#private
NSString* _data;
}
#end
is necessary? To further that, is it ever necessary to use #synthesize? My understanding is that using #property will auto-synthesize both the accessor methods as well as the backing ivars. I've done some experimentation and I noticed that when I don't declare NSString* _data', I can still access_data' in my class implementation. Does that mean that declaring ivars come down to a matter of style, up to the discretion of the programmer? Could I condense my code and remove all ivar declarations in the statement blocks in my implementation and just use #property in my private interface? If that's not the case, what are the advantages and disadvantages of explicitly declaring ivars?
Finally, #dynamic. From what I can gather, it's used to say to the compiler, "Hey compiler, don't auto-generate the accessor method and don't worry if you don't find an implementation for it, I'll provide one at runtime". Is that all #dynamic is used for or is there more to it?
I just want to clarify all these things because it seems like there's a lot of different opinions and that there's not necessarily one right answer. Plus as Objective-C grows and progresses, those answers will change so it'll be nice to have a concise and up-to-date guide. Thanks everyone!
(Also if there's anything that I could word better or make clearer, let me know)
EDIT:
In summary, what I'm asking is this:
1) Is declaring ivars with modern Objective-C necessary?
2) Can I achieve the same effects of declaring ivars and corresponding properties by just using #property?
3) What is #dynamic used for?
4) Can I completely forgo the use of #synthesize or is there a good use case for it?
Upvote and down vote as you see fit.
There's a lot to answer here. I'll break it down:
Declaring ivars
As you've correctly noted, modern versions of the compiler will synthesize backing instance variables for declared #properties. The exception to this is on 32-bit Macs, where the modern Objective-C runtime, including non-fragile instance variables, is not available. Assuming your application is not targeting 32-bit OS X, you don't need to explicitly declare the backing ivar for an #property.
If you still want to use an ivar directly, without a corresponding #property (something I consider a bad idea most of the time), you of course must still explicitly declare the ivar.
#dynamic
#dynamic is as you've said meant to tell the compiler "don't synthesize accessors for this property, I'll do it myself at runtime". It's not used all that often. One place it is used is in NSManagedObject subclasses, where if you declare a modeled property in the header, you don't want to compiler to complain that there's no implementation of accessors for that property, nor do you want it to generate accessors itself. NSManagedObject generates accessors for modeled properties at runtime. The story is similar for custom CALayer subclasses.
#synthesize
#synthesize explicitly tells the compiler to synthesize accessor methods, and (on iOS and 64-bit Mac) a corresponding ivar for the specified property. There are three main cases where you still need to use it:
32-bit Mac apps.
If you've written your own custom setter and getter (or just getter for readonly properties). In this case, the compiler won't synthesize accessors because it sees yours. However, it also won't synthesize the backing ivar. So, you must use #synthesize someProperty = _someProperty;, to tell the compiler to synthesize an ivar. It still won't synthesize accessor methods of course. Alternatively, you can explicitly declare a backing ivar. I favor using #synthesize in this case.
If you want to use a different name for the property's backing ivar than the default (property name with an added underscore prefix). This is rare. The main case I can think of for using it is when transitioning existing, older code, that includes direct ivar access and where the ivars are not underscore-prefixed.
Best current practice seems to be to use properties for all ivars placing the property either in the .h file if they are to be exposed and in the .m file in a class extension if local to the class.
No #synthesize is needed unless the ivar needs to be different than the underscore prepended property name.
Yes, #dynamic is as you describe.
Further, it is no longer necessary to declare local instance methods or order such that the method is above the use.
First off, #synthesize is gone for these scenarios: do not have to do it any more.
Secondly, you don't need the private ivar anymore either.
So in essence, you can just do properties.
The way of controlling access is the same idiom that had become popular before MOC dropped: put the property in the public interface as readonly and then make a readwrite version in the private interface (which should be, as you show above, merely the name with open and close parens).
Note also, that many of the things that cluttered up the public interface in the past can now ONLY be in the private interface, so for instance IBOutlets, etc., since the controller is going to be the only thing diddling them.
I never see #dynamic used anywhere except in CoreDate-generated entities.
For someone who first worked with C++ where the dream was always that the header/interface merely show the user of the class what they needed and all other details would be hidden, I think MOC (Modern Objective C) is a dream come true.
BTW, highly recommend the intro session from WWDC Modern Objective C (from 2012) and the one this year was great too.
I'm just wondering about semantics. When is something truly a "property" of an object? I noticed in a lot of Apple's APIs, they explicitly define getters and setters instead of using properties (e.g. URL and setURL on NSURLRequest/NSMutableURLRequest; surely the URL seems like a "property" of an URL request, right?) I'm wondering if there's some subtle thing that I'm missing or if Apple just doesn't like properties all that much. =P
UPDATE: As of iOS 8, Apple has converted most (if not all) of their non-property getters and setters to properties. (Probably done so that Swift compatibility would be easier.)
or if Apple just doesn't like properties all that much.
The real cause is that most of the Foundation framework (let's not forget you're talking about NS* classes) is old as dirt - they have been around there since the NeXT times... At that time, the Objective-C language didn't sport the #property keyword - to emulate properties, it was necessary for the programmers to declare and implement getter and setter methods manually, this applied to Apple's code as well.
Now the Foundation framework is so fundamental that it hasn't changed a lot. It hasn't been radically rewritten and as far as I'm concerned, programmers who wrote it didn't bother rewriting all the code using the new syntax. You can see that recently added classes do in fact feature declared properties instead of getters and setters, but that's not true for older classes.
Anyway, properties declared manually and those declared using #property and #synthesize are completely equivalent. That said, there's a very minor difference when accessing them, but that doesn't belong to the declaration thingy: if you write
someObject.someProperty
in your code, the someObject must have a complete and concrete type, so if a property named someProperty is nonexistent, you'll get a compiler error. In contrast,
[someObject someProperty]
and
[someObject setSomeProperty:]
allow you the method call even if it's undeclared.
Edit:
I ask what the semantic difference between them is
So by "semantic difference", you meant "when it should be used" rather than "does it run differently". I see. Well... Conceptually, properties represent state. A property is a particular characteristic of an object that may change over time. It's just an unrelated fact that properties are accessed using accessor methods in Objecive-C.
If you write a method that acts on the obejct (other than setting a property, of course), there's a fair chance you should be declaring and calling it as a method. If you access (read or write) an attribute of an object, that better fits the task of a property.
Having a getter and setter lets you use messages to access the item
[myObject someProperty] or [myObject setSomeProperty: someNewValue]
Making something a #property gives you the additionally ability to use dot notation to call the getter and setter. This is because #property chooses method names that make the class key-value-coding compliant for the particular value.
myObject.someProperty or myObject.someProperty = someNewValue
While it is possible to do this manually, it is considered best-practice to use #property when you want to use the dot notation. Over time, the behind-the-scenes bahaviours of #property and #synthesize have changed quite a bit particularly in regard to auto-creating storage for the associated pointer. Using #property makes it easier to keep up with Apple's changes in convention with little or no change in your code.
Additionaly, using #property makes your code much easier to read.
When using Objective-C properties can you stop creating instance variables altogether or do explicit instance variables (not the ones synthesized by the properties) still serve a purpose where properties would be inappropriate?
can you stop creating instance variables altogether
No, you can't (in a sense). What you can do is stop declaring them if you have properties. If you synthesize a property and you haven't declared the instvar, it will get declared for you, so you are creating an instance variable, just not explicitly.
do they still serve a purpose where properties would be inappropriate?
It used to be the advice to create properties for everything because having synthesized properties does almost all of the retains and releases for you. However, with ARC that reason for using properties to wrap the memory management has gone away. The advice now (for ARC) is, I believe, use properties to declare your external interface, but use direct instance variables where the variable is part of the object's internal state.
That's a good reason to adopt ARC: properties revert to their true purpose only of being part of the class's API and it's no longer necessary to use them as a hacky way to hide memory management work.
Edit
One more thing: you can now declare instance variables in the #implementation so there is now no need to leak any implementation details in the #interface. i.e.
#implementation MyClass
{
NSString* myString;
}
// method definitions
#end
And I'm pretty sure it works in categories too. - see comment below
I recommend declaring everything as properties and avoiding manual ivars altogether. There is no real upside to manually creating ivars. Declare public properties in your header #interface, declare private properties in a private class extension in your .m file.
To some of JeremyP's points, internal use of accessors still has significant value under ARC, even though memory management is no longer a significant concern. It ensures that KVO works properly, subclasses better, supports custom setters (particularly for things like NSTimer), supports custom getters (such as for lazy instantiation), etc. It is exceedingly error-prone to have a mix of accessors and ivars. It's far too easy to forget which you need to access in which way. Consistency is the hallmark of good ObjC.
If you absolutely must declare an ivar for some reason, then you should do it in the #implementation block as JeremyP notes.
UPDATE (Oct-2013):
Apple's guidance (From Programming with Objective-C: Encapsulating Data):
Most Properties Are Backed by Instance Variables
In general, you should use accessor methods or dot syntax for property access even if you’re accessing an object’s properties from within its own implementation, in which case you should use self:
...
The exception to this rule is when writing initialization, deallocation or custom accessor methods, as described later in this section.
This question was addressed before here
When you use synthesize the instance variables are handled and instantiated for you. If you're using Lion with the new version of XCode also take a look at the various properties in ARC in Transitioning to ARC
you can always access properties from outside. So if you want a variable only to be read from inside a class you still have to declare a iVar. Also accessing a public ivar with object->ivar is slightly faster than using a method-call.
So in the guidelines it says:
For code that will run on iOS only, use of automatically synthesized instance variables is preferred.
When synthesizing the instance variable, use #synthesize var = var_; as this prevents accidentally calling var = blah; when self.var = blah; is intended.
// Header file
#interface Foo : NSObject
// A guy walks into a bar.
#property(nonatomic, copy) NSString *bar;
#end
// Implementation file
#interface Foo ()
#property(nonatomic, retain) NSArray *baz;
#end
#implementation Foo
#synthesize bar = bar_;
#synthesize baz = baz_;
#end
Question is, does this apply to public variables only or private too? It's not really clear on the documentation, but would like to have some thoughts or perspective on why "if" this is only for public or private only? I think that it just makes sense for all public/private so that you don't mess up ivars and using the property
I don't think it particularly matters whether the variables in question are public or private. The practice of synthesizing under a different name makes it explicit when you are accessing the variable directly instead of using the generated accessor method.
Perhaps there's a different question underlying what you're asking: should I typically access private ivars via the accessor or directly? I think most skilled iOS devs tend to use accessors unless there is some particular reason not to (performance, avoiding side effects like KVO, etc.). Doing so is more future-proof and allows for flexibility in the underlying implementation. In a very small way, you're coding to an interface rather than an implementation.
It also might be worth pointing out that the default behavior of Clang is going to change in the future so that property-backing ivars are synthesized named _foo by default. Clearly the powers-that-be consider consider underscoring ivars to be a best-practice.
I am pretty sure much of it comes down to personal preferences, so here are mine, for what they are worth:
I like to distinguish between public properties and "private" instance vars.
Properties are always accessed through their accessors, except for initialization (and within a manually created accessor method, for obvious reasons). Hence, the underscore in the backing ivar is useful, and not really an issue in my daily use of the properties.
Instance vars are used to hold state that is used internally in the methods, but not (directly) by other classes.
I have become very fond of declaring my instance variables in the .m file. Nice, clean and easy (no switching back and forth between .h and .m to declare ivars).
I find that this distinction helps me clear my mind and determine if a property is something outside agents should get and/or set directly (a property in .h), or if it is really just a help to get my method implementations to work (an ivar in .m).
I'd agree with Paul.s. that consistency is your friend, but to me, distinction is a friend, too.
I am a bit confused about encapsulation. In general (or in Obj-C), does it mean separation of interface/implementation OR does it imply access of ivars through methods ?
Please clarify. Thank you.
Actually, Both.
As nacho4d said, you encapsulate instance variables within your class and prevent direct access to them by using methods and properties to read and write their values. This ensures that the instance can always know when something has read or written a value whereas direct ivar access is no different from setting a value in a C struct.
However, the separation of #interface from #implementation also contributes greatly to encapsulation. And one of the goals of the enhancements to the language in the past few years has been to increase the degree of encapsulation offered by that separation.
Namely, the class's primary #interface can now contain only the parts of your class that you want other developers/code to interact with. The public interface, if you will. All of the implementation details can be moved out of the #interface in the latest compilers, including all instance variables.
The latter. From wikipedia:
A language mechanism for restricting
access to some of the object's
components.
Specifically in Objective-C an ivar will be #protected by default, so they only can be accessed within the same class or subclasses. can change it to #private or #public as you need.
The methods you mentioned are accessors (getters and setters) and in that case you probably want to use #properties since they can be defined in 1 line and you can set some attributes like retain, assign, copy, readonly, etc.
Read further on properties here (Apple doc)
Hiding of Class methods and variables from once class to other is called encapsulation.