Re: Why so many public properties all up in my grizzle?
Re: Why so many public properties all up in my grizzle?
- Subject: Re: Why so many public properties all up in my grizzle?
- From: Luther Baker <email@hidden>
- Date: Fri, 16 Mar 2012 19:02:37 -0500
A few points worth clarifying for the original poster here ...
Using a @property does NOT actually expose the underlying implementation.
@properties are like configurable ACCESSORS ... they do *NOT* necessarily
provide direct access to the implementation. You can implement them however
you want. You can @synthesize them, make them readonly, return something
computed from them ... or do all sorts of work when trying to "set" them.
It is really up to you to be careful what you decide to expose. Consider
that in Java, one must often write
public void setName(String name) { this.name = name; }
public String getName() { return this.name}
@properties can give you this type of behavior in a 'declaratory' way. They
are actually very powerful as this is only *one* example of how they can be
used. Consider attributes such as assign, readonly, atomic ... there are
loads of semantics that you can apply to your accessors by changing just a
few words in one line:
@property (readonly) NSString *name;
Dig into them here.<http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ObjectiveC/Chapters/ocProperties.html>
They
are more than just a convenience. They are succinct. They are
self-describing. If used correctly - they are very very consistent with
standard OO practices. You can think of them as syntactic sugar for
well-known and used OO patterns - but some would suggest they are much more
powerful than that.
And with respect to your original IB implementation, note that Interface
Builder can bind to ivars that are not formally declared as @property. For
example, you may do this:
@interface MyViewController {
@private
IBOutlet UILabel *labelMyLabel;
IBOutlet UIButton *buttonDoIt;
}
The ivars are not exposed, IB finds them ... all is well - and the code
looks more or less like any other OO language that declares the ivars in
the headers. Now, whether or not THAT is a good practice is a different
debate and has implications far beyond the scope of Objective-C or Cocoa
for that matter (ie: declaring ivars in the implementation files).
Security and runtime implications aside, you can write excellent OO code
with a liberal use of @properties in Objective-C but as Bjarne once
said<http://www2.research.att.com/~bs/bs_faq.html#really-say-that>:
"*C makes it easy to shoot yourself in the foot; C++ makes it harder, but
when you do it blows your whole leg off" *and likewise, @properties can be
abused if not understood or used incorrectly.
Hope that helps,
-Luther
On Fri, Mar 16, 2012 at 5:53 PM, Jens Alfke <email@hidden> wrote:
>
> On Mar 16, 2012, at 2:57 PM, Eeyore wrote:
>
> > So simply hiding the actions in the implementation doesn't protect you
> from finding out the method's name and calling it.
>
> Well, sure. If you’re in the same process, there’s nothing protecting you
> from malicious code. The same goes for C++ or assembly; it’s just a little
> easier to find the method’s entry point in Obj-C because there’s more
> metadata.
>
> The point of not declaring internal methods in the header isn’t for
> security, it’s to prevent accidentally using internal APIs in places where
> you shouldn’t. If a class considers property X as part of its internal
> state, then other code in the project shouldn’t use X, so you want to make
> sure that accidentally referring to X produces a compile error.
>
> —Jens
>
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> 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:
>
> This email sent to email@hidden
>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden