Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Rule 9 in Object Calisthenics by Jeff Bay (RTF) is:

Rule 9: No getters/setters/properties

The last sentence of the previous rule leads almost directly to this rule. If your objects are now encapsulating the appropriate set of instance variables but the design is still awkward, it is time to examine some more direct violations of encapsulation. The behavior will not follow the instance variable if it can simply ask for the value in its current location. The idea behind strong encapsulation boundaries is to force programmers working on the code after you leave it to look for and place behavior into a single place in the object model. This has many beneficial downstream effects, such as a dramatic reduction in duplication errors and a better localization of changes to implement new features.

Another way this rule is commonly stated is “Tell, don’t ask”.

I get the point of the rule. But I find it only useful in garbage collected environments where modifying a reference is very simple.

Will this be of any help in Objective C? Because it's always important to let only setter change the ivar and let it also take care of retaining new value and releasing the old one. and use the setter anywhere inside methods to alter ivars which are pointers.

share|improve this question
up vote 2 down vote accepted

I think this rule is about public getters/setters/properties.

It's OK to let objective-c properties handle retaining/releasing providing that you don't make them public. You can use categories to make properties private.

That way you have the best of both worlds:

  • you don't break encapsulation
  • you manage memory properly and easily
share|improve this answer
Nice. I posted the same question on SO as well but got weird answers. – Amogh Talpallikar Mar 1 '12 at 11:10
BTW is this your post… ? – Amogh Talpallikar Mar 1 '12 at 11:34
@AmoghTalpallikar : no, this isn't – David Mar 1 '12 at 12:12

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.