StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

POProper usage of @private variables / properties
primarykey
Id
12437379
data
AcceptedAnswerId
12437460
AnswerCount
2
ClosedDate
CommentCount
0
CommunityOwnedDate
CreationDate
2012-09-15T12:28:43.370
FavoriteCount
1
LastActivityDate
2012-09-17T23:36:05.723
LastEditDate
2012-09-17T17:39:07.027
LastEditorUserId
1010171
OwnerUserId
1010171
ParentId
0
PostTypeId
1
Score
3
ViewCount
243
LastEditorDisplayName
text
Body
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: <pre><code>@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 </code></pre> The Implementation looks like this: <pre><code>@implementation Car @synthesize make, model, numberOfBackSeatPassengers; @end </code></pre> Now here's the Sportscar class: <pre><code>#import "Car.h" @interface Sportscar : Car @property int turboEngineSize; @end </code></pre> And its implementation: <pre><code>#import "Sportscar.h" @implementation Sportscar @synthesize turboEngineSize; @end </code></pre> In "main" I have this: <pre><code> 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]; </code></pre> 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: <pre><code>-(void) setNumberOfBackSeatPassengers:(int)numPassgeners { numberOfBackSeatPassengers = numPassgeners; } -(int)numberOfBackSeatPassengers { return numberOfBackSeatPassengers; } </code></pre> 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 <code>performSelector</code>. I say "theoretically", cause in my case its not quite working correctly: if - in "main" - I call <code>[sportscar1 performSelector:@selector(setNumberOfBackSeatPassengers:)];</code> then I get some junk number inserted for <code>numberOfBackSeatPassengers</code> 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 <code>Sportscar</code> we can simply override the <code>Car</code> class's setter and getter for <code>numberOfBackSeatPassengers</code>, 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 <code>@private</code> not really seeming to do what it ought to do. 3) Redesigning the logic to have a class for <code>FourDoorCar</code> and another one for <code>TwoDoorCar</code> 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 <code>@private</code> 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 <code>@private</code> 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 <code>@private</code>, 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 <code>@private</code> in the Header (as opposed to in the ".m") that would somehow benefit me? I thought <code>numberOfBackSeatPassengers</code> 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 <code>numBackSeatPassengers</code> 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 <code>phantomIVar</code> :-) And so: <pre><code>@interface Car : NSObject { @private //int numberOfBackSeatPassengers; int phantomIVar; } @property (nonatomic, strong) NSString *make, *model; @end </code></pre> The Implementation would be: <pre><code>@implementation Car @synthesize make, model; -(void) setPhantomIVar:(int)i { phantomIVar = i; } -(int)phantomIVar { return phantomIVar; } @end </code></pre> Which pretty much puts us back where we started :-) At least that's how I feel. I mean the only thing that the <code>@private</code> declaration seems to buy us is readability. So that now, anyone looking at the Header will be able to see that <code>phantomIVar</code> 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 <code>@private</code> in front of <code>phantomIVar</code> 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, <code>@private</code> 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 :-)
Tags
<iphone><objective-c><instance-variables><private-members>
Title
Proper usage of @private variables / properties
singulars
PostAcceptedAnswerId
1. PO
 singulars
 PostTypePostTypeId
 PTAnswer
PostParentId
1. This table or related slice is empty.
PostTypePostTypeId
1. PTQuestion
UserLastEditorUserId
1. USsirab333
UserOwnerUserId
1. USsirab333
plurals
PostLinksPostIdRelatedPostId
1. PL
 singulars
 LinkTypeLinkTypeId
 LTLinked
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. This table or related slice is empty.
PostsParentIdCreationDate
1. PO
 singulars
 PostTypePostTypeId
 PTAnswer
2. PO
 singulars
 PostTypePostTypeId
 PTAnswer
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 POProper usage of @private variables / properties
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
2. VO
 singulars
 PostPostId
 POProper usage of @private variables / properties
 UserUserId
 USJessedc
 VoteTypeVoteTypeId
 VTFavorite
3. VO
 singulars
 PostPostId
 POProper usage of @private variables / properties
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId
1. This table or related slice is empty.

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.