.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.



Comments

  • There are no comments yet. Be the first to comment!

Leave a Comment
  • Your email address will not be published. All fields are required.

Top White Papers and Webcasts

  • Live Event Date: October 29, 2014 @ 11:00 a.m. ET / 8:00 a.m. PT Are you interested in building a cognitive application using the power of IBM Watson? Need a platform that provides speed and ease for rapidly deploying this application? Join Chris Madison, Watson Solution Architect, as he walks through the process of building a Watson powered application on IBM Bluemix. Chris will talk about the new Watson Services just released on IBM bluemix, but more importantly he will do a step by step cognitive …

  • Live Event Date: October 29, 2014 @ 1:00 p.m. ET / 10:00 a.m. PT It's well understood how critical version control is for code. However, its importance to DevOps isn't always recognized. The 2014 DevOps Survey of Practice shows that one of the key predictors of DevOps success is putting all production environment artifacts into version control. In this eSeminar, Gene Kim will discuss these survey findings and will share woeful tales of artifact management gone wrong! Gene will also share examples of how …

Most Popular Programming Stories

More for Developers

Latest Developer Headlines

RSS Feeds