CODEWITHSUNDEEP
objective-ccocoa-touchcocoa
fumoboy007
fumoboy007

Reputation: 5543

When to use properties vs. plain ol' getters and setters

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.)

Upvotes: 1

Views: 229

Answers (2)

Jeff Wolski
Jeff Wolski

Reputation: 6372

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.

Upvotes: 1

user529758
user529758

Reputation:

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.

Upvotes: 8

Related Questions