30

I jumped in to a project and I see that the other developers are adding a lot of logic in the setters of synthesized properties. I understand how this works, but I think that it makes it hard to understand the flow of the program; while reading the code, whenever I see self.something = whatever, I always check if something's setter is overridden.

What are your opinions around this topic? Do you think this is a sign of bad architecture or an elaborate solution?

I would be glad to read more on this if you have relevant links/sources, it's just too hard to get good google results so I decided to ask here as well.

Thanks for any answer and please note that I'm talking about objective C in case you haven't seen the tag (even though this shouldn't be a language specific issue I guess).

phi
  • 423
  • 4
  • 5
  • 5
    What sort of logic? There is nothing wrong in putting validation logic, for example. On the other hand, a setter which dispatches a few events, calls a web service and updates the UI is completely wrong. – Arseni Mourzenko Jul 13 '13 at 21:50
  • @MainMa I agree that validations are fine -- maybe adding some observers as well, right? Could you maybe give some examples of what you consider as more appropriate to put in a setter? – phi Jul 13 '13 at 22:00
  • indeed, observers are right. As for the things which are appropriate for a setter, I let more experienced developers answer this question. – Arseni Mourzenko Jul 13 '13 at 22:08

3 Answers3

47

Is it considered a bad practice to add logic in a property setter?

No

Properties were invented to allow class designers to have logic attached to a convenient interface of field access and assignment.

How much is too much? It depends on the responsibilities of the class. Here are some things that are reasonable to put in a property setter:

  • update some derived values
  • notify observers that the class state has changed
  • propagate the change to some contained object
  • propagate the change to a backing store
  • perform validation

Programming is easier when classes have interfaces that make it obvious what the class can do, without making callers think about how it is being done. Putting logic behind property setters allows classes to hide their implementation behind a simple interface. For some classes, no methods are required. Just turn the knobs by setting properties and read the output by getting properties.

kevin cline
  • 33,608
  • 3
  • 71
  • 142
16

Setters are typically used to change the state of an object with no significant side effects or heavy calculations;use methods and functions for that. The primary reason for setter implementation is changing and maintaining a valid state. So, limiting range, setting flags to request recalculation, or adjusting related properties is absolutely fine.

Rob van der Veer
  • 406
  • 2
  • 6
7

I don't know about objective C, but as you say, it seems a generic enough question for any OO language. First of all and actually related to that, whether to have setters and getters in the first place is a matter of discussion (in some cases their existence is justified by the use of a framework or library).

I believe that the name of the method should explain what the method does and all the method does. Additionally the documentation associated to that method should describe it in a more explicit way. In this sense a method name in the form "set" + {noun} shouldn't have any side effects other than setting the value of a variable and that should be the only action associated to it. Checking that the argument is valid, is acceptable but it should be described in its documentation.

DPM
  • 1,713
  • 1
  • 16
  • 24
  • 1
    +1 for "whether to have setters and getters". And another +1 for "method name should explain what it does". – aviv Jul 14 '13 at 20:33