Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JavaWorld.com

C#: A language alternative or just J--?, Part 2

The semantic differences and design choices between C# and Java

By Mark Johnson, JavaWorld.com, 12/21/00

  • Print
  • Feedback
.

Page 3 of 5

Properties

Directly accessing the public data members of objects is generally understood to be poor form. Direct access to a data member of an object inherently breaks data encapsulation and is a maintenance hazard. When a data member is removed from an existing class, any code that accesses that removed member will also need to be fixed. Further, code that accesses a class's public data members relies on a particular implementation of that class. The traditional solution to this problem is to provide "accessor methods," or "getters" and "setters," which provide access to information about the object. The value set retrieved by an accessor method is typically called a "property." For example, a block of text in a word processor might have properties like "foreground color," "background color," and so on. Instead of exposing public Color members, the object representing a block of text could provide getter and setter methods to those properties. This concept of using access methods to encapsulate internal virtual object state is a design pattern that spans object-oriented languages. It isn't limited to C# or Java.

C# has taken the concept of properties a step further by actually building accessor methods into the language semantics. An object property has a type, a set method, and a get method. The set and get methods of the property determine how the property's value is set and retrieved. For example, a TextBlock class might define its background color property in this way: 

public class TextBlock {
   // Assume Color is an enum
   private Color _bgColor;
   private Color _fgColor;
   public Color backgroundColor {
      get {
         return _bgColor;
      }
      set {
         _bgColor = value;
      }
   //... and so on...
   }
}


(Notice in the preceding set block _bgColor is set to value, which is a keyword that, in this context, means the value of the property.) Some other object could set or get a TextBlock's backgroundColor property like this: 

TextBlock tb;
if (tb.backgroundColor == Color.green) { //
"get" is called for comparison
   tb.backgroundColor = Color.red;  // "set" is
called
} else {
   tb.backgroundColor = Color.blue;  // "set"
is called
}


So, the syntax to access a property looks like a member but is implemented like a method. Either of the get and set methods is optional, providing a way of creating "read only" and "write only" properties.

Some would say that Java has properties, since the JavaBeans specification defines properties in terms of method naming conventions and the contents of JavaBean PropertyDescriptors. While JavaBeans properties do everything C# properties do, JavaBeans properties are not built into the Java language, and so the syntax for using them is a method call: 

TextBlock tb;
public class TextBlock {
   private Color _bgColor;
   public Color getBackgroundColor() {
      return _bgColor;
   }
   public Color setBackgroundColor(Color value_) {
      _bgColor = value_;
   }
   // ...etc...
}
TextBlock tb;
if (tb.getBackgroundColor() == Color.green) {
   tb.setBackgroundColor(Color.red);
} else {
   tb.setBackgroundColor(Color.blue);
}


The meaning of the preceding example code in Java and C# is identical, but the syntax in C# is cleaner.

  • Print
  • Feedback

Resources