.NET Tip: Restrict the Access to Your Properties!

I recommend using a read-only interface to prevent unwanted changes to inherited properties. I work with location data constantly when tracking various assets, so I use a GPSLocation class to keep track of location, speed, and direction data. Then, in my Asset class, I use a GPSLocation to keep track of the asset’s most recent position. The original GPSLocation and Asset classes looked like this:

public class GPSLocation
{
   private double _Latitude;
   private double _Longitude;
   private int _Speed;
   private int _Direction;

   public GPSLocation(double Latitude, double Longitude,
                      int Speed, int Direction)
   {
      _Latitude = Latitude;
      _Longitude = Longitude;
      _Speed = Speed;
      _Direction = Direction;
   }

   public double Latitude
   {
      get { return _Latitude; }
      set { _Latitude = value; }
   }

   public double Longitude
   {
      get { return _Longitude; }
      set { _Longitude = value; }
   }

   public int Speed
   {
      get { return _Speed; }
      set { _Speed = value; }
   }

   public int Direction
   {
      get { return _Direction; }
      set { _Direction = value; }
   }
}

public class Asset
{
   private GPSLocation _MostRecentLocation;

   public GPSLocation MostRecentLocation
   {
      get { return _MostRecentLocation; }
      set { _MostRecentLocation = value; }
   }
}

The problem I ran into was that there were places in my application where I wanted the properties of the GPSLocation class to be read-only. With the current state of the GPSLocation and Asset classes, I could directly change the value of Speed, or any other property, in the asset’s MostRecentLocation.

GPSLocation Location = new GPSLocation(39, -86, 50, 180);
Asset A1 = new Asset();
A1.MostRecentLocation = Location;
// This is what I wanted to prevent
A1.MostRecentLocation.Speed = 120;

Here, I create a new GPSLocation and Asset and then assign the GPSLocation to Asset.MostRecentLocation. Everything is all right up to this point. The next line of code is the problem. Any property of the GPSLocation can be changed by accessing it directly through the Asset.MostRecentLocation property. I wanted the properties of Asset.MostRecentLocation to be read-only, allowing it to only be set as a complete GPSLocation unit. The answer to my problem is an interface. Using a read-only interface and slight modifications to the GPSLocation and Asset classes allow me to achieve the results I desired. Take a look at the interface and class changes to see how this is done.

public interface IReadOnlyGPSLocation
{
   double Latitude { get; }
   double Longitude { get; }
   int Speed { get; }
   int Direction { get; }
}

public class GPSLocation : IReadOnlyGPSLocation
{
   // Nothing inside the GPSLocation class changed
}

public class Asset
{
   private GPSLocation _MostRecentLocation;

   public IReadOnlyGPSLocation MostRecentLocation
   {
      get { return _MostRecentLocation; }
      set { _MostRecentLocation = (GPSLocation)value; }
   }
}

Having the GPSLocation class implement the IReadOnlyGPSLocation interface and changing Asset.MostRecentLocation to return the interface, instead of a GPSLocation, allows the properties of Asset.MostRecentLocation to be read-only. Now, the code above that assigned a value to the Speed property produces a compile-time error.

Property or indexer "CS_Tips2.IReadOnlyGPSLocation.Speed"
cannot be assigned to -- it is read only

I now have a means to enforce the read-only status of Asset.MostRecentLocation properties at compile-time. I no longer have to worry about other layers of the application accidentally changing location values. Using interfaces is a great way to provide different views into a class, as you can see in this example.

About the Author

Jay Miller is a Software Engineer with Electronic Tracking Systems, a company dedicated to robbery prevention, apprehension, and recovery based in Carrollton, Texas. Jay has been working with .NET since the release of the first beta and is co-author of Learn Microsoft Visual Basic.Net In a Weekend. Jay can be reached via email at jmiller@sm-ets.com.

More by Author

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Must Read