Question

I often have a hard time deciding if certain data should be exposed through a property or a method. You can say “use properties for object state”, but that’s not very satisfying. Take this example for instance:

- (NSString *)stringOne
{
    return _stringOne;
}

- (NSString *)stringTwo
{
    return _stringTwo;
}

- (NSString *)mainString
{
    return [_stringOne length] > 0 ? _stringOne : _stringTwo;
}

It’s clear that stringOne and stringTwo should be properties because they are clearly object state. It’s not clear, however, if mainString should be a property. To the end user mainString acts like state. To your object, mainString is not state.

This example is contrived but hopefully you get the idea. Yes, properties are nothing more than a convenient way to create getters and setters but they also communicate something to the user. Does anyone have decent guidelines for deciding when to use a property vs a method.

Answer 1

Hiding the split between “true” state (string1 and string2 in your example) and “dynamic” state (mainString) is, I would say, exactly what properties are for.

The canonical example would probably be an object that represents a person, with given and family names as “state”. A third piece of state, “full name” can be presented from those two pieces, but clients have absolutely no reason to know whether the full name is constructed on demand, or is created and stored when both of its pieces are set. It simply doesn’t matter.

Properties are an interface — what bits of data does this class provide to its clients (and what can the clients configure about the class)? The implementation of each property is encapsulated and does not affect its status as a property.

In ObjC, of course, we use methods to access properties. Other methods, however, represent actions that an object can take, possibly being passed some piece of data to operate on.