title: Why do we use .NET properties instead of plain old get/set functions?
body: <p>I understand the many benefits of providing an interface to access the members of a class indirectly. My question is: isn't that already something you can accomplish in just about any OO language using (something along the lines of)</p>
  
  <pre><code>public int NormalClass::getQuality() {
      return this-&gt;quality;
  }
  </code></pre>
  
  <p>and</p>
  
  <pre><code>protected void NormalClass::setQuality(int q) {
      this-&gt;quality = q;
  }
  </code></pre>
  
  <p>?</p>
  
  <p>What additional benefits do .NET properties offer, beyond sheer aesthetics?</p>
  
  <p>I will accept "readability" if you can make a compelling argument for it; but personally, I'm inclined to think a get/set function is more readable than a property since it is unambiguously a <strong>function</strong> as opposed to a straight-up value.</p>
  
  <p><strong>EDIT:</strong> Thanks to everybody for answering! This has been really informative for me; to sum up what I've gathered/learned from all that has been said, the following are a few conclusions I've reached so far:</p>
  
  <ul>
  <li>The greatest benefits of properties
  come not from specific features of
  properties themselves, but rather
  from framework and IDE features which
  handle properties in a special way;
  e.g., the Properties editor, XML
  serialization, data binding.   </li>
  <li>Properties can be treated as simple
  values in certain convenient ways
  that get/set functions can't: in
  particular, obj.Prop++ and obj.Prop =
  value.</li>
  <li>Properties let you get away
  with quick and dirty code using
  public members without going through
  the headache of implementing a bunch
  of get/set functions later; if you
  should ever need to add some logic
  and/or make a public member private,
  you can simply introduce a property
  and not risk breaking any old code.</li>
  </ul>
  
  <p>Now, there is one point that's been made in 2 or 3 of the answers so far that I personally find somewhat dubious: that properties imply inexpensive read/write operations and can therefore be used in essentially the same way as simple variables. My issue with this point is that there is nothing inherent in properties that actually enforces this; it is simply how they are <strong>supposed</strong> to be used. To me, this is analogous to a "shouldBePrivate" qualifier that indicates a value <em>should</em> be accessed directly only by its own class, but which can still be accessed externally anyway; or a police force that patrols the streets to remind us that we <em>should</em> behave ourselves, but does not actually interfere when we start committing crimes (if it isn't enforced, what is it really doing for us?).</p>
  
  <p>I'd be more impressed by this point if properties had some sort of built-in mechanism for ensuring read/write cheapness.</p>