Welcome to the Treehouse Community

Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community! While you're at it, check out some resources Treehouse students have shared here.

Looking to learn something new?

Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.

Start your free trial

iOS Build a Blog Reader iPhone App Data Modeling Creating a Custom Class: Part 1

Jonathan Fernandez
Jonathan Fernandez
8,325 Points

Setter and Getter Methods for title and author the same as @property?

Setter and getter methods feel like a lot of work and I just want to clarify if they are the same as @property. If not then how are they different? I just had to ask because they were used in this video and I feel like there must be a reason we are using this longer method instead of the simple @property.

<p>
//Is this...
-(void)setTitle:(NSString *)title;
-(NSString *)title;

// the same as this?
@property (strong, nonatomic) NSString *title;
</p>

Any feedback will be greatly appreciated. : )

4 Answers

Florian Goussin
Florian Goussin
8,925 Points

You have to think an object as a black box (encapsulation): nobody is supposed to know what's under the hood. So you have to provide an interface for the client (in that case also you) to be able to control it. This interface is most of the time composed by the public methods (with the getters and setters) and some public constants.

A very basic example is a car object. You are never going to move the wheels manually by choosing an angle appropriate but you will rather use the steer or direction function.

To go back to the getters and setters a check could be, if the client is supposed to enter a string parameter for let say setName(), you could test if the string parameter is not null, is a string or is not empty. In a setEmail() you can check the right formatting.

If you want to force the client to use the setter you have to make the property private. So it won't be possible to modify it from outside and consequently you need generally to provide a function to read that private property: the getter. You don't have to have each time a getter and a setter for all the properties. Some properties could be only accessible from inside. From inside the class you are not the client but the architecte, so you usually use directly the properties.

I hope it'll be clearer.

Boaz Keren Gil
Boaz Keren Gil
18,947 Points

I'm a bit confused.. So when I'm using the setters and getters inside a specific class the @property is enough? and when I'm using the setters and getters to connect different kinds of classes I'll use the long version?

I get that sometimes you will need to test if the string is not null, too short, too long, etc.. but in this video he doesn't do any tests in his setters and getters.. so why not make things shorter and use @property?

Florian Goussin
Florian Goussin
8,925 Points

Usually the setter is useful if you include some tests into it. You cannot test the property if you modify it directly. The cool thing is that you can change whenever your want the setter function without affecting the code which use the object. For a very basic ex, you can change the name of the property when you want. So you first create a basic setter and later on you can implement some checkings whenever you want.

Moreover it help to abstract the internal representation of an object. An object is a kind of API (Application Programming Interface) and you're just the client of this, so you can only use the public methods.

Then you need a getter to read the private property.

http://stackoverflow.com/questions/1568091/why-use-getters-and-setters

Jonathan Fernandez
Jonathan Fernandez
8,325 Points

Thank you for the feedback. I sort of get you, but still have a hard time visualizing what kind of test I would need to run. Although I think i'll start to get it more when I venture into more complex apps since I'm super new at coding. In the later videos though I want to note that he ended up replacing the setter and getter methods with the @property. Like you said it helps show the internal representation of the object, I think they just wanted to make that distinction clear and present noobies with this first before telling them that @property, @synthesize, +newer versions of Xcode have better ways to make this process shorter.