All my research shows that there's no real usage for the #private directive - so I must be missing something and need you experts to chime in :-)
Assume we have 2 classes: a Car class and a SportsCar class, where SportsCar is a subclass of Car.
Here's the Car class:
#interface Car : NSObject {
NSString *make;
NSString *model;
#private
int numberOfBackSeatPassengers; // I'm making this a private iVar cause I'm just gonna
// say that all Sportscars will be 2-seaters and therefore shouldn't
// be able to set/get the number of back-seat passengers
}
#property (nonatomic, strong) NSString *make, *model;
// Now here's my first issue: if I also make "numberOfBackSeatPassengers" an #property
// then it seems like all subclasses of this Car class *WILL* be able to access it as
// well - even though I declared it as #private - but I'll do this anyway to make my point:
#property int numberOfBackSeatPassengers;
#end
The Implementation looks like this:
#implementation Car
#synthesize make, model, numberOfBackSeatPassengers;
#end
Now here's the Sportscar class:
#import "Car.h"
#interface Sportscar : Car
#property int turboEngineSize;
#end
And its implementation:
#import "Sportscar.h"
#implementation Sportscar
#synthesize turboEngineSize;
#end
In "main" I have this:
Car *car1 = [[Car alloc] init];
[car1 setMake:#"Chevy"];
[car1 setModel:#"Impala"];
[car1 setNumberOfBackSeatPassengers:3];
Sportscar *sports1 = [[Sportscar alloc] init];
[sports1 setMake:#"Audi"];
[sports1 setModel:#"tt"];
[sports1 setNumberOfBackSeatPassengers:3];
Obviously I'm able to set the NumberOfBackSeatPassengers on the Sportscar - even though that iVar was declared as #private - but that's because I made it an #property in "Car.h" which means that the synthesized getter and setter for it are Instance Methods, thereby available to all subclasses of Car.
The other option would have been to NOT declare numberOfBackSeatPassengers as an #property in "Car.h", keep it there as only a simple iVar, and instead manually create a Setter and Getter for it in the #implementation of "Car.m" like this:
-(void) setNumberOfBackSeatPassengers:(int)numPassgeners {
numberOfBackSeatPassengers = numPassgeners;
}
-(int)numberOfBackSeatPassengers {
return numberOfBackSeatPassengers;
}
This would have made the getter and setter for numberOfBackSeatPassengers available only within "Car.m" - which I suppose would make them "private" - but they'd be too private: I could never call them from Main, or from anywhere outside of "Car.m" Moreover, and this is the real point: doing it this way means the #private directive back in "Car.h" doesn't really come into play at all in any of this. I mean I could now go back to "Car.h", take out the "#private" directive there -- and my manual setter and getter for numberOfBackSeatPassengers would still work exactly the same as they are now, being supposedly private - so what's to be gained with "#private"? How does it truly come into play?
Can anyone shed any real light on this?
(And yes, I know I can extend my Car class in the #interface section of the "Car.m" file - through a category, or make numberOfBackSeatPassengers a readonly property first, then change it to readwrite, etc. - but these all seem like workarounds or "hacks" to making "#private" work. I just don't get how #private truly works on its own.)
=====================================================
EDIT - in response to aroth's comments below:
1) aroth's absolutely correct in saying that a subclass could still theoretically call a method that was NOT declared in its parent class's Header -- by using performSelector. I say "theoretically", cause in my case its not quite working correctly: if - in "main" - I call
[sportscar1 performSelector:#selector(setNumberOfBackSeatPassengers:)];
then I get some junk number inserted for numberOfBackSeatPassengers cause I can't explicitly pass-in a number as an argument when calling the method this way.
(Question: is there a way around this?)
2) aroth's also absolutely right in saying that in Sportscar we can simply override the Car class's setter and getter for numberOfBackSeatPassengers, and have these overriding methods reset it to 0, or give an error, etc. But while this is a very practical solution and seems to solve this particular problem, I feel like it doesn't address the larger issue of #private not really seeming to do what it ought to do.
3) Redesigning the logic to have a class for FourDoorCar and another one for TwoDoorCar and then continue building off of that is an interesting option - but that almost feels like now Objective-C's syntax is "forcing" itself on my programming logic and how I'm structuring my very project - and this feels like quite an imposition. Maybe I'm wrong and making too much out of this - but either way this all came about just because the #private isn't doing what it seems to promise...? Doesn't feel right.
At the end of the day I keep coming back to the same question: what good does #private actually do us? What benefits does it have, what does it "buy" me? It seems that if I want to have an iVar be private, I can just declare it in the ".m" file and not ever bother declaring it in the Header file in the first place. I mean am I right about this or not? or is there still some instance where you'd want to declare an iVar in the Header as #private, but not declare a setter and getter for it there in the Header - so those won't be explicitly available to subclasses - and have it all make sense?
Can we think of an actual example for this? Is there some sort of Car property that I'd want to declare as #private in the Header (as opposed to in the ".m") that would somehow benefit me?
I thought numberOfBackSeatPassengers would be a good example, but I'm not seeing how it'd really work in action, in actual code...
=========================================================================
EDIT #2 - Continuing the dialogue with #aroth :-)
#aroth - I absolutely agree that its much better/more organized to declare all iVars in the Header and not split things up so that some are in the Header and some are in the Implementation. That creates a mess and I really dislike that approach. (I noted in my original question that I don't want to use the Implementation and/or Category approach to address my question.)
-Also, yes, properties absolutely don't always have to be backed up by iVars.
-Regarding designing the Class appropriately, I concur that that of course is the key to good programming. The Car/Sportscar example is something I made up on the spot to give my question some context and I didn't invest any time considering its design merits/flaws. I think if we were to take your approach however - which seems quite logical for sure - and go with a Car class, a FourDoorCar subclass, a TwoDoorCar subclass, etc. - we could solve a lot of problems - but its still very likely that sooner or later we'll run into a situation where we'd perhaps want an #private iVar for one of our classes, and not want to create another subclass to deal with it.
I mean lets just assume that this would happen, for the sake of this discussion.
And so, if possible, I'd really like to think of a specific iVar for our Car class that it would make sense to have as #private, show in code how to use it, and discuss its scope and limitations.
I keep trying to think of a real-world example of some property of a Car that we would want only the Car to have - and that none of its subclasses should inherit.
I really thought numBackSeatPassengers would do the trick - and for the purposes of our discussion it still can, but, I'll just make up another one and call it phantomIVar :-)
And so:
#interface Car : NSObject {
#private
//int numberOfBackSeatPassengers;
int phantomIVar;
}
#property (nonatomic, strong) NSString *make, *model;
#end
The Implementation would be:
#implementation Car
#synthesize make, model;
-(void) setPhantomIVar:(int)i {
phantomIVar = i;
}
-(int)phantomIVar {
return phantomIVar;
}
#end
Which pretty much puts us back where we started :-)
At least that's how I feel.
I mean the only thing that the #private declaration seems to buy us is readability. So that now, anyone looking at the Header will be able to see that phantomIVar is an iVar of Car, and understand that its private. That's it.
In terms of functionality however, it didn't seem to do much. Cause its not like putting #private in front of phantomIVar freed us up to still be able write a setter/getter for it in the Header and have those be only accessible to Car class objects and not subclasses of Car. No, #private doesn't get you that. To get privacy you'd have to go in the Implementation file and write your setter and getter there. And ultimately in Objective-C there's no such thing as private methods. In Obj. C. they're all public.
aroth, please let me know if I got this right - and if not, where exactly I went wrong.
Many thanks :-)
This would have made the getter and setter for
numberOfBackSeatPassengers available only within "Car.m"
Not true. Those methods would still exist on every instance of Car and every instance of every object that extends Car, whether or not you declare them in your header file. The compiler wouldn't treat them as publicly visible and would complain if you tried to call them directly, but you'd still be able to call your getter and setter on any subclass of Car simply by using performSelector:.
In any case, if you have a #property there's no point is using #private on the ivar that backs it (and there's also no point in having an explicit ivar backing it, one will be created automatically for you when you use #synthesize; but that's a separate topic). I'd suggest that if SportsCar is meant to extend Car and never allow any backseat passengers to be recorded that the 'standard' way to do that would be to simply override the getter/setter methods in SportsCar to either always set/return 0 or to raise some error if an attempt is made to set a nonzero value.
Another option, since this property does not apply to all Car instances is to take it out of the base class entirely. You could, for example, have Car, and then derived from that have TwoDoorCar and FourDoorCar, and then have SportsCar be derived from TwoDoorCar. In this case you could declare numberOfBackSeatPassengers as a public property of FourDoorCar, as every four-door car should be able to accommodate passengers in the back seat.
To get back to the original question being asked, using #private on an ivar affects only the visibility of that ivar. It does not affect methods which make use of the ivar. So a subclass of Car will not be able to see the numberOfBackSeatPassengers ivar itself. But since you've created a public getter/setter for it, the subclass will of course be able to see those, and use them to modify the value of the ivar.
Edit
To briefly answer the updated question(s):
Yes, you can use NSInvocation to dynamically invoke a method that requires primitive parameters. Or you can use the approach discussed here, which is even more straightforward: Objective-C and use of SEL/IMP. Or you can use a NSNumber instead of an int and then use performSelector:withObject:.
I'm not sure what you're saying #private should be doing in this case. What is it that you think using #private should do?
I think this has less to do with syntax and more to do with principles of object-oriented design. If some cars do not have a back seat, then it is not really good object-oriented design to give the Car superclass a numberOfBackseatPassengers property. Doing that gives the object a field that does not actually apply to every instance of the object type. And when you start doing that you run into exactly the sort of problems you describe in your example. The purpose of a superclass is to contain functionality that is common to all of its derived types. If it has functionality that is common only to some of its derived types, then that is usually a design problem. In any case, it has nothing to do with Objective-C syntax or semantics.
As for what #private gets you, how about simplified organization of your class, for one thing? Yes you can declare an ivar in your implementation file to accomplish a similar effect, but is that really as convenient as having all the ivars declared in the header? On a reasonably complex project, will other developers be able to follow your code as easily if only some ivars are declared in the header and the rest are in the implementation file?
Without #private/#protected every ivar declared in a header would be public, which is definitely not good in an object-oriented environment for all the reasons Jonathan pointed out. So these access modifiers probably exist, first and foremost, to solve this issue.
As for use-cases, properties with getters/setters are probably not the best example. The purpose of getters/setters is virtually always to provide a public interface for modifying/querying the property value, and as noted in Objective-C it's not necessary to explicitly declare an ivar, in any scope, to back a synthesized property.
A better example may be IBOutlet's. You want these declared in your header so that XCode/Interface Builder can find them, but you don't want them exposed outside of your class implementation or (typically) even to subclasses of your class. So you would declare them in your header, and you generally would not add any getter/setter methods for these ivars.
Edit 2
For a specific example of where #private makes sense, what about something like:
#interface Car : NSObject {
#private
DataRecorder* blackBoxRecorder;
}
#property (nonatomic, strong) NSString *make, *model;
#end
We know that proposed regulations may require all cars on the road to include a built-in black-box/data recorder. So every Car must have one, and no subclass of Car should be able to tamper with blackBoxRecorder.
In this case having a setter method defined would not make sense. You might provide a public getter, or instead you might provide a public wrapper API around the DataRecorder that subclasses could use to log data. Something like -(void) logEventWithName:(NSString*)name andValue:(NSNumber*)value;. So subclasses can use the DataRecorder through the API, but they can't mess with the backing ivar itself to disable or modify the behavior of the mandated black-box/data recorder.
But in any case, yes, I'm in general agreement with your analysis. Having #private mostly impacts readability/maintainability of code. It needs to exist for Objective-C to be successful as an object-oriented programming language (if all ivars were public by default and there was no way to modify that, the language would be a complete mess), but what it does from a purely functional standpoint is not much. It's more of a logical/organizational tool. It assists with data hiding and allows you to keep all of your ivars in your header file(s), and that's about it.
You can declare the property as readonly in the Car class itself, or re-declare it as readonly only in the SportsCar class.
Also, #private doesn't have anything to do with properties - it only modifies the scope of the ivar itself.
Related
So I'm not sure how this works. I briefly looked at a coworker's C# (I'm not a .NET developer), and I see a lot of stuff that gets passed into methods would be some class object that conforms to an interface. Is this something that is good to do in objective-c as well?
For example, I'm messing around with the MapKit API and I created my own class that conforms to the MKAnnotation protocol so I can have custom views and some extra properties for the typical pin that gets dropped on the map. I plan on using this class I created,
Address : NSObject
as opposed to the MKPlacemark class when I place pins on the map. In my other view controllers and model classes, do I do:
#property (nonatomic, strong) id <MKAnnotation> object; //1
or
#property (nonatomic, strong) Address *object; //2
I started with the example 1, but then when I actually needed some of the properties of the Address object, I found myself having to typecast the object anyway which seemed like what's the point, or I'm missing the point? So I guess my end question is, is 1 or 2 better, and in what scenarios? Thanks.
I would go with option 3 which would look like this:
Address : NSObject <MKAnnotation>
Then when you implement the class, implement the methods required to conform to the MKAnnotation protocol.
This way you can have the best of both worlds.
Protocols are very similar to interfaces in languages such as C# or Java. One of the main differences is the ability to require certain methods and have other methods be optional. Since Objective-C is such a dynamic language, you'll see a number of calls such as [foo responseToSelector:#selector(someSelector:)]. If -someSelector: was marked as optional, you would need to check to see if the receiver "responds" to that message. If it were marked as required, however, the compile would throw up a warning if you didn't implement that method. Take a look at the Objective-C Language Reference for more information
You cannot use strong keyword for id type, use this instead:
#property (nonatomic, assign, readwrite) id<MyDelegate> delegate;
When I need a private object I currently use properties, like so:
// Class extension in .m file
#interface MyClass()
#property (strong, nonatomic) NSArray* myInternalArray;
#end
self.myInternalArray = something;
Alternatively you can do this:
#implementation MyClass {
NSArray* _myInternalArray;
}
_myInternalArray = something;
Without a custom setter or getter the two are equivalent. What is the best practice for internal variables? Are there any advantages of one method over the other?
While some may argue that the choice is a matter of preference, and they do have a point, there is a very good reason that most modern languages support properties and make them easier and easier to code.
The introduction of ARC does not significantly reduce the value of properties. It all comes down to this - in a property you have encapsulated the use of a variable. That encapsulation is invaluable when needed, and not much overhead when it is not.
For example (off of the top of my head) Suppose you discovered that you needed to validate the value before saving it. If you were using an iVar, you would have to ensure that anywhere that iVar was used, you had a call the validation code before you allowed it's value to be changed. With a property, you would only need to override setIVarName: and put the validation there. One could argue that one is just as easy as the other - and that may be true in many cases, but there is one handicap with the iVar here - you cannot ensure that future changes (by you or other coders) will insert the validation before the iVar is changed. Using a property here does have that assurance.
Personally, I use properties over iVars where ever possible.
I'd say that the advantage of properties is that you would use setters, and that setters can evolve independently of the code that call them. For instance, you could decide that setting a property would now trigger setNeedsLayout. By using properties from the start, you would have no need to refactor existing code.
This pattern fits very well in Cocoa/iOS APIs, where you don't have to ask system objects to do anything after having changed their properties: setters ensure internal and UI consistency right away.
The fact that properties are private should not make us implement them as second-class properties, what do you think?
I've looked through a bunch of posts on this subject. Maybe I didn't run across "the one" and someone will point me in that direction. The question is simple and probably has a simple answer.
If you have two ivars, say, "public_ivar" and "private_ivar", where/how should you declare them so that what is public is public and what is private is not exposed in any way to anyone looking at the header file?
Same question in the case of "public_method" and "private_method".
I like clean header files (in other languages) that only expose the methods and ivars I want someone else to see. You should be able to publish your header file and not run into the danger of someone accessing something they are not supposed to. How do you do that in objective-C.
For example, let's say that I decide that I need to use an ivar to keep track of some data, a counter or somthing like that, between various class methods that all need access to this information. If that ivar is declared conventionally in the header under #interface its existence is publicly advertised and it is usable by anyone creating an instance of the class. The ideal scenario would be that this ivar would not be visible at all outside of the class implementation.
You can declare instance variables or declared properties in a class extension. Since a class extension is declared in an implementation file (i.e., not a header file), they won’t be visible to someone inspecting the header file. For instance, in the header file:
#interface SomeClass : NSObject
#end
and in the implementation file:
#interface SomeClass ()
#property (nonatomic, assign) int privateInt;
#end
#implementation SomeClass
#synthesize privateInt;
…
#end
or
#interface SomeClass () {
int privateInt;
}
#end
#implementation SomeClass
…
#end
Note that there’s nothing preventing access to private/class extension instance variables (or the accessor methods for properties declared in a class extension) during runtime. I’ve written a rather detailed post about this as an answer to another question on Stack Overflow: Does a private #property create an #private instance variable?
Edit: Instance variables in class extensions were presented in WWDC 2010 session 144.
Edit: "Using the Clang/LLVM 2.0 compiler, you can also declare properties and instance variables in a class extension."
http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ObjectiveC/Chapters/ocCategories.html#//apple_ref/doc/uid/TP30001163-CH20-SW1
Use class extensions to add to a class in your implementation file. A class extension is basically an unnamed category with a few bonuses: properties declared in it can be synthesized and anything declared in it must be in the main implementation, so the compiler can check to make sure you didn't miss an implementation. You must put the class extension before your implementation. You can't add instance variables directly in a class extension, but you can add properties. When you synthesize accessors for properties which don't have corresponding instance variables, the new runtime (os x 10.5 and later and all versions of iOS, I believe) will create the instance variables automatically. This means you can't create your own accessors, however, unless you put the instance variable in your header. Private methods can be added to the class extension without restriction, but as Anomie noted, it is technically possible to use them if you know what they are called, and with class-dump, nothing is safe.
Example usage of a class extension:
#interface MyClass ()
#property (retain) id privateIvar;
#property (readwrite) id readonlyProperty; // bonus! class extensions can be used to make a property that is publicly readonly and privately readwrite
- (void)privateMethod;
#end
#implementation MyClass
#synthesize privateIvar; // the runtime will create the actual ivar, and we just access it through the property
- (void)privateMethod {
...
}
...
Another way of creating "instance variables" without putting them in the header or using a property is to use associative references, which add data to an object at runtime. They aren't technically the same as instance variables, and the syntax for them is more complex. Since they also require the new runtime, there are only two reasons you would ever really want to use them: you want to add an instance variable in a category (outside the scope of this question) or you need it to be really really private. An associative reference doesn't create any methods or add to the class's definition in the compiled code, so if you don't create wrappers for them it is impossible to find out about them without asking the object after you add the data. See the bottom of the page I linked for a complete usage example.
You can use #private to specify that ivars are private. There is no way to make a method private, however. Even if the method is not listed in the header file, if someone knows the name and arguments they can call it.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
What describes #property(…) best? What's that actually good for?
If I declare a variable in my class interface, I can use such variable anywhere on my class. Awesome.
If I use #property (retain) Something *myVar; I can access that variable with self.myVar... But, what is the difference? Is there a good reason I should use one method or another?
Short answer: Encapsulation of memory management.
Longer answer: You need to establish ownership of an object if you want to use it later. If you want to use it later, you'll need a reference to it with which to do so, and a great place to keep that reference is in an instance variable.
You could handle the ownership claims (i.e. retains and releases) each time you assign a new value to that, but that would leave a lot of repetitious and trouble-prone boilerplate code scattered all over the place, like cherries in a fruitcake. That kind of mess is fiendishly difficult to debug when (not if) something goes wrong. So, it's far better to wrap that code up in accessor methods, so you can write it once and then forget about it.
But accessor methods are mostly boilerplate too, so we use #property declarations to create them automagically, rather than writing them by hand.
Edit: Apple's Memory Management Guide provides a lot of detail about what the accessor methods generated by #property do behind the scenes.
If I use #property (retain) Something *myVar; I can access that variable with self.myVar... But, what is the difference?
#property (retain) Something *myVar;
// this property declaration declares:
- (Something *)myVar;
// and
- (void)setMyIvar:(Something *)arg;
// and is accessible by dot syntax.
// it also declares and/or documents how the ivar is managed (copy, retain, etc.)
in use:
// direct access to the ivar. zero additional overhead (with regard to accessing the ivar)
[myVar message];
// properties used with dot syntax invoke the accessor. therefore,
[self.myVar message];
// is the same as:
[[self myVar] message];
the property's properties also give instructions to the compiler as to how to synthesize an accessor.
Is there a good reason I should use one method or another?
in init and dealloc, access the ivar directly - you are interested in initialization and cleanup of the object's ivars and do not care about subclasses. using properties here can also introduce bugs or undefined behavior.
for other cases, that is, when the object is in a fully constructed state, you should always use the accessor for consistency. if a subclass overrides an accessor, direct access of the ivar could break designs.
if you want to avoid this, then make the ivar private and do not declare a property for it. if you do declare a property for it, then document that it is private; i'll typically write #property (retain) Something * private_myIvar; in this case. in this case, it is convenient to use a property to synthseize the ivar's memory management.
when the ivar is private, you have total access to it. it is safe to access directly or by private property. otherwise, assume that you must use the accessor.
if myIvar is declared private and will be created only at initialization, you can avoid declaring the properties altogether. this will reduce runtime overhead (if that is critical). messaging overhead, retain/release cycles, and atomics will (naturally) require more execution time. so it can be bypassed to improve performance.
visibility/maintenance. sometimes, it's far less maintenance/implementation to hide an ivar from the interface. in other cases, the ivar is an implementation detail of the class, and should not be a part of the public interface. in such cases, consider making it private (there are a few ways to accoomplish this in objc).
Using the #property to access your ivars, does a lot of the repetitive code of releasing and retaining objects for you. You don't have to use them. It's just a lot of tutorials make it simple for people that are new to the platform.
First off, please forgive the stupidness of this question but Im not from a C/C++ background. I'm a little unclear about what the difference in roles between the .h and .m files when it comes to properties.
I understand the concept of interfaces, and I see that in part the .h file is an interface for the implementation, but what I am not clear on is this:
Why are properties/methods defined outside of the {} braces?
What am i defining in the braces when I write something like this:
IBOutlet UITextField *numberField;
Is this a field definition in an interface?
When I am adding the #Property lines to the .h files are these actual implementations of a n auto property or just an interface blueprint? If so is the #syntesis the actual implementation?
I guess my biggest confusion seems to be that if I want a property I'm defining what I need in three different places (1) in the interfaces braces, (2) as #property outside the braces and (3) with #synthesis in the .m file. This seems long winded, but its fine if I can work out what these three parts do.
Cheers, Chris.
I'll answer your questions below, but perhaps the best way to learn this stuff is to read some user-friendly notes intended for folks new to the language, such as the Learn Objective-C tutorial over at cocoadevcentral.
An example
I'd like to help answer your questions with an example (I love learning by example). Let's say you're a teacher writing a program that asks students a particular yes/no question, and keeps track of how many get it correct and how many students it has asked.
Here is a possible interface for this class:
#interface Question : NSObject {
NSString* questionStr;
int numTimesAsked;
int numCorrectAnswers;
}
#property (nonatomic, retain) NSString* questionStr;
#property (nonatomic, readonly) int numTimesAsked;
#property (nonatomic) int numCorrectAnswers;
#property (nonatomic) int numWrongAnswers;
- addAnswerWithTruthValue: (BOOL) isCorrect;
#end
The three variables inside the braces are instance variables, and every instance of your class will have its own values for each of those variables. Everything outside the braces but before #end is a declaration of a method (including the #property declarations).
(Side note: for many objects, it's useful to have retain properties, since you want to avoid the overhead of copying the object, and make sure it isn't released while you're using it. It's legal to retain an NSString as in this example, but it is often considered good practice to use copy instead of retain since an NSString* might actually point to an NSMutableString object, which may later change when your code expects it to stay the same.)
What #property does
When you declare a #property, you're doing two things:
Declaring a setter and getter method in the class's interface, and
Indicating how the setter and getter behave.
For the first one, it's enough to know that this line:
#property (nonatomic, retain) NSString* questionStr;
is basically the same as this:
- (NSString*) questionStr; // getter
- (void) setQuestionStr: (NSString) newQuestionStr; // setter
in the header. You literally are declaring those two methods; you can call them directly, or use the dot notation as a shortcut to call them for you.
The "basically" part in "basically the same" is the extra info given by keywords like nonatomic and retain.
The nonatomic keyword indicates that they're not necessarily thread-safe. The common retain keyword indicates that the object retains any value that's set, and releases previous values as they're let go.
For example:
// The correct answer to both questions is objectively YES.
Question* myQuestion = [[Question alloc] init];
NSString* question1 = [[NSString alloc] initWithString:#"Is pizza tasty?"];
// question1 has retain count of 1, from the call to alloc
myQuestion.questionStr = question1;
// question1 now has a retain count of 2
NSString* question2 = [[NSString alloc] initWithString:#"Free iPhone?"];
myQuestion.questionStr = question2;
// question1 has a retain count of 1, and question2 has retain count of 2
If the #property declaration for questionStr had been assign instead, then all the myQuestion.questionStr = statements would not have made any changes at all to the retain counts.
You can read a little more about properties here.
What IBOutlet and IBAction do
These are basically no-op words which act only as a way to tell Interface Builder which pieces of the header file to pay attention to. IBOutlet literally becomes an empty string when the compiler looks at it, and IBAction becomes the void return value. We do need them to work with Interface Builder, though, so they are important -- just not to the compiler.
Quick note on C structs and arrow vs dot notation
By the way, the data part of an Objective-C object is very similar to a C struct. If you have a pointer to a C struct, you can use arrow notation -> to refer to a specific part of the struct, like this:
struct MyStructType {
int i;
BOOL b;
};
struct MyStructType* myStruct;
myStruct->i = 3;
myStruct->b = TRUE; // or YES in Objective-C.
This same syntax works the same way in Objective-C:
Question* question = [[Question alloc] init];
question->questionStr = #"Is this a long answer?"; // YES
But when you do this, there is no method call happening behind the scenes, unlike the dot notation. With the dot notation, you're calling the setter (or getter if there's no = afterwards), and these two lines are the same:
question.questionStr = #"Chocolate?";
[question setQuestionStr:#"Chocolate?"];
It's often a good idea to avoid the arrow notation in favor of the dot notation, since the dot notation lets you enforce valid state -- for example, that the pointers your class has are always retained. You can even disallow others from using the arrow notation by declaring your instance variables as #private; they can still use the getter and setter to access it, if you declare a #property for it.
What #synthesize does
Now, when you get around to actually implementing your class, #synthesize says something like "make sure the getter and setter get implemented for this property." It does not say "implement both of these for me," because the compiler is polite enough to check for your own implementation first, and only fill in the pieces you've missed. You don't have to use #synthesize at all, even if you use #property out the wazoo -- you could always just provide your implementations for your setters and getters, if you're into that sort of thing.
You probably noticed in the Question interface above that there's a property which is not an instance variable (numWrongAnswers), which is fine because you're just declaring methods. In the example code here, you can see how this actually works:
#implementation Question
#synthesize questionStr, numTimesAsked, numCorrectAnswers;
- (void) setNumCorrectAnswers: (int) newCorrectAnswers {
// We assume the # increases, and represents new answers.
int numNew = newCorrectAnswers - numCorrectAnswers;
numTimesAsked += numNew;
numCorrectAnswers = newCorrectAnswers;
}
- (int) numWrongAnswers {
return numTimesAsked - numCorrectAnswers;
}
- (void) setNumWrongAnswers: (int) newWrongAnswers {
int numNew = newWrongAnswers - self.numWrongAnswers;
numTimesAsked += numNew;
}
- (void) addAnswerWithTruthValue: (BOOL) isCorrect {
if (isCorrect) {
self.numCorrectAnswers++;
} else {
self.numWrongAnswers++;
}
}
#end
One thing that's happening here is we're faking an instance variable called numWrongAnswers, which would be redundant information if we stored it in the class. Since we know numWrongAnswers + numCorrectAnswers = numTimesAsked at all times, we only need to store any two of these three data points, and we can always think in terms of the other one by using the two values we do know. The point here is to understand that a #property declaration is really just about declaring a setter and getter method, which usually corresponds to an actual instance variable -- but not always. The #synthesize keyword by default does correspond to an actual instance variable, so that it's easy for the compiler to fill in the implementation for you.
Reasons to have separate .h and .m files
By the way, the whole point of declaring methods in one file (the .h header file) and defining their implementation in another (the .m or methods file) is to help decouple the code. For example, if you only update one .m file in your project, you don't have to recompile the other .m files, since their object code will remain the same -- this saves time. Another advantage is that you can use a library that includes only header files and pre-compiled object code, or even dynamic libraries where you need the header file so the compiler is aware of which methods exist, but those methods aren't even linked in with your executable file. These advantages are hard to appreciate when you first start coding, but just the logical breakdown and encapsulation of implementation becomes useful after a short while.
I hope that's helpful!
methods are defined outside of the braces since the braces are meant to encapsulate the state of the object which can be argued does not include the instance or class methods.
What you are defining in the braces are instance variables that can be referenced as self.ivar
The #property and #synthesize directives simply setup accessors for you instance variables so you can set them by doing self.ivar = someVar. So in other words it sets up the "dot syntax" for you to use.
and to answer your finale question: To define a property or instance variable simply declare it in your .h file as a variable inside the braces. To setup accessor methods on that same property you need to do BOTH #property and #synthesize.
Well that is just Objective C syntax, methods and #property outside {} and variables inside {}.
#property is the way of telling that you are going to write getter and setters (kind of enforcing it), but you can write getter/setter without setting them #property. #property is in .h file because its declaration. And why it is outside {}, well as i said before its just the syntax, what we can do?
#synthesis will in actual implement getter and setters, if you dont synthesis but you have set them #property, you have to implement those getter and setters by your hand. And #synthesis is in .m file because its implementation.
Something more for you to read on this subject can be find here.
http://theocacao.com/document.page/510
The variables inside the brackets define the physical structure of your class. Those are the actual instance variables that store information.
The stuff outside the brackets make up the class's interface — methods and properties. A property in and of itself does not reserve any storage space or affect any variable — it just declares a generic interface for accessing something. Remember that a property doesn't have to have an underlying instance variable — for example, the totalPrice property in a ShoppingCart class might dynamically sum the prices of all the items in the cart.
Inside the implementation file, you tell the class how to actually do its work. For methods, obviously, you just supply an implementation. For a property, you can either provide accessor implementations yourself or ask it to synthesize accessors for an instance variable.