David Duncan indicates that some of this can be alleviated with newer runtimes, but Objective C's messaging system allows you to send messages to objects even if those messages are not declared in the object's interface. So simply hiding the actions in the implementation doesn't protect you from finding out the method's name and calling it.
Another issue (not Obj-C specific) is that all the frameworks that I've used that connect graphically developed UIs with code required the classes to expose the point of connection. Your completely coded example is a little more protected from malicious coders, but not completely, as a hacker would still have access to the controller's view and could walk the subviews making changes. The convenience I get by being able to lay my views out graphically comes at the expense of requiring me to expose my outlets (so that the system can connect my code and my nib). I don't think there could be any way for the system to make those connections without making the outlets publicly available. Specific comments on your example, below: On Mar 16, 2012, at 2:00 PM, Brian Lambert wrote: > #import <UIKit/UIKit.h> > > // MyViewController interface. > @interface MyViewController : UIViewController > > // Properties. > @property (weak, nonatomic) IBOutlet UILabel * labelMyLabel; I suspect that the UILabel ought to be strong, but that's not really the topic here. > // buttonDoItTouchUpInside action. > - (IBAction)buttonDoItTouchUpInside:(id)sender; > > @end > > This means that my UILabel called labelMyLabel is publicly available. > Anyone who has access to an instance of MyViewController can do anything > they want to with my label, including replacing it. In your implementation, you (probably) have something like @synthesize labelMyLabel=_labelMyLabel; This means that labelMyLabel may be public but the actual data _labelMyLabel is private. If you are really concerned about someone tinkering with the labelMyLabel, you can try to intercept access to labelMyLabel by implementing your own custom getter/setter. But if you want the runtime to connect your label to your class, you are going to need to allow outsiders to set your label at some point (possibly repeatedly as your view unloads and loads due to memory warnings). > Also, anyone who has an instance of MyViewController can call my > buttonDoItTouchUpInside action. If you don't want to expose this, then you can expose the button through a IBOutlet and manually connect the action in viewDidLoad. I actually prefer to connect actions manually because then if I have multiple nibs for the same class (e.g., an iPhone and an iPad nib for the same controller), I don't have to try to remember to set all the actions, just the outlets. > Everyone, all the books, training materials, samples, and so on, just seem > to accept this style of doing things as being normal. In fact, one book I > read *encouraged* this technique of using public properties for ALL the > internal state of a class over using ivars. It said public properties were > preferable. The ivars are your data, the properties are just getter/setter methods that access that data (with some syntactic sugar that makes it look like data access). I would guess that the author was suggesting to make all data access go through getter/setter properties instead of direct ivar access. I think they were comparing "public property vs. public ivar" and proposing the use of public properties (getter/setters) instead of direct data manipulation. Aaron _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
