17 January 2007I recently had an email discussion where I was describing why I needed to solve the problem I described in
<?xml:namespace prefix = o ns = “urn:schemas-microsoft-com:office:office” />
The question he posed to me was whether it was a good idea to have a property set block actually change the value. In most programming models, goes the thought, assigning a property to a value can’t result in that property value changing. So any changes to the value that occur in the set block of a property are counter-intuitive, and so you simply shouldn’t change the value in the setter code.
Here’s my response:
The idea of a setter (which is really just a mutator method by another name) changing a value doesn't (or shouldn't) seem counter-intuitive at all. If we were talking about assigning a value to a public field I’d agree entirely. But we are not. Instead we’re talking about assigning a value to a property, and that’s very different.
If all we wanted were public fields, we wouldn't need the concept of "property" at all. The concept of "property" is merely a formalization of the following:
- public fields are bad
- private fields are exposed through an accessor method
- private fields are changed through a mutator method
- creating and using accessor/mutator methods is awkward without a standard mechanism