17.6.2.htm

This ECMA Standard specifies the form and establishes the interpretation of programs written in the

   }  
   public Point Location {  
      get { return new Point(x, y); }  
   }  
   public string Caption {  
      get { return caption; }  
   }  
}  
</pre></span></span><span class="paragraph"><span class="example">Here, the Label class uses two <span class="keyword">int</span> fields, x and y, to store its location. The location is publicly exposed both as an X and a Y property and as a Location property of type Point. If, in a future version of Label, it becomes more convenient to store the location as a Point internally, the change can be made without affecting the public interface of the class: <pre class="code-example">
class Label  
{  
   private Point location;  
   private string caption;  
   public Label(int x, int y, string caption) {  
      this.location = new Point(x, y);  
      this.caption = caption;  
   }  
   public int X {  
      get { return location.x; }  
   }  
   public int Y {  
      get { return location.y; }  
   }  
   public Point Location {  
      get { return location; }  
   }  
   public string Caption {  
      get { return caption; }  
   }  
}  
</pre></span></span><span class="paragraph"><span class="example">Had x and y instead been public readonly fields, it would have been impossible to make such a change to the Label class. end example]</span> </span><span class="paragraph"><span class="note">[Note: Exposing state through properties is not necessarily any less efficient than exposing fields directly. In particular, when a property is non-virtual and contains only a small amount of code, the execution environment may replace calls to accessors with the actual code of the accessors. This process is known as inlining, and it makes property access as efficient as field access, yet preserves the increased flexibility of properties. end note]</span> </span><span class="paragraph"><span class="example">[Example: Since invoking a get accessor is conceptually equivalent to reading the value of a field, it is considered bad programming style for get accessors to have observable side-effects. In the example <pre class="code-example">
class Counter  
{  
   private int next;  
   public int Next {  
      get { return next++; }  
   }  
}  
</pre>the value of the Next property depends on the number of times the property has previously been accessed. </span></span><span class="paragraph"><span class="example">Thus, accessing the property produces an observable side effect, and the property should be implemented as a method instead. end example]</span> </span><span class="paragraph"><span class="note">[Note: The "no side-effects" convention for get accessors doesn't mean that get accessors should always be written to simply return values stored in fields. Indeed, get accessors often compute the value of a property by accessing multiple fields or invoking methods. However, a properly designed get accessor performs no actions that cause observable changes in the state of the object. end note]</span> </span><span class="locator">
     Paragraph 9</span><span class="paragraph"><span class="sentence"><span class="sentence-number">1</span> <a name="P9S1"></a>Properties can be used to delay initialization of a resource until the moment it is first referenced.</span> <span class="example">[Example: For example: <pre class="code-example">
using System.IO;  
public class Console  
{  
   private static TextReader reader;  
   private static TextWriter writer;  
   private static TextWriter error;  
   public static TextReader In {  
      get {  
         if (reader == null) {  
            reader = new StreamReader(Console.OpenStandardInput());  
         }  
         return reader;  
      }  
   }  
   public static TextWriter Out {  
      get {  
         if (writer == null) {  
            writer = new StreamWriter(Console.OpenStandardOutput());  
         }  
         return writer;  
      }  
   }  
   public static TextWriter Error {  
      get {  
         if (error == null) {  
            error = new StreamWriter(Console.OpenStandardError());  
         }  
         return error;  
      }  
   }  
}  
</pre></span></span><span class="paragraph"><span class="example">The Console class contains three properties, In, Out, and Error, that represent the standard input, output, and error devices, respectively. By exposing these members as properties, the Console class can delay their initialization until they are actually used. For example, upon first referencing the Out property, as in <pre class="code-example">
Console.Out.WriteLine("hello, world");  
</pre>the underlying TextWriter for the output device is created. But if the application makes no reference to the In and Error properties, then no objects are created for those devices. end example]</span> </span><span class="ruler"></span><table><tr><td><table align="left" bgcolor="navy"><tr bgcolor="navy"><td><font face="Arial,sans-serif" size="6" color="yellow"><strong>{ JSL }</strong></font></td></tr></table></td></tr><tr><td><font face="Arial,sans-serif" size="2" color="navy"><strong>Jagger Software Ltd</strong></font></td></tr><tr><td><font face="Arial,sans-serif" size="2" color="navy"><strong>Company # 4070126</strong></font></td></tr><tr><td><font face="Arial,sans-serif" size="2" color="navy"><strong>VAT # 762 5213 42</strong></font></td></tr></table><img src="valid-html401.png" align="left" height="31" width="88" alt="Valid HTML 4.01" /><img src="vcss.gif" align="left" height="31" width="88" alt="Valid CSS" /></body></html>