Should I make this a read only property or a function.

Question

So in my COM wrapper I have a property like this:

public string Name
{
    get
    {
        //Call the COM object
        //Work the returned object
       //Return the name.
    }
}

I was doing some reading on read-only properties vs function and was wondering if I should change this to a function instead, something along the lines of:

public string getName
{
       //Call the COM object
       //Work the returned object
       //Return the name.
}

What do you think?

Answer 1

One factor to take into account: if the code can take a "long" time to run, making it a function makes that slightly more obvious when you're reading the calling code. It's easy to unconsciously assume that name = myObject.Name; is near-instant.

Answer 2

Edit: I'm going to try to lay this all out, because I see this question coming up over and over. Feel free to edit and contribute to my answer.

The standard coding design standard is :

• Don't do work in properties.

• Do work in Methods.

Consider this extreme example:

Car c = new Car();
Console.WriteLine( c.Color );

By just writing that code above, would you expect the property Color to be doing this:

public string Color {
  get{
      CarFactory cf = new CarFactory();
      cf.AddWheels();
      cf.AddSteeringWheel();
      cf.AddEngine();
      cf.PaintCar( Color.Red );
      return cf.BuildCar().Color;
  }
}

It's sneaky hidden code that you wouldn't think to be there.

But it would make total sense if the same code where:

Car c = CarFactory.BuildNewCar();
c.Color = Color.Red;

While looking for documentation for you I ran accross: http://msdn.microsoft.com/en-us/library/ms229006.aspx

Which says (rather vaguely): "...properties should not be computationally complex or produce side effects."

It also states "If a getter might throw an exception, consider redesigning the property to be a method."

While it is completely possible that an exception could be thrown while using the COM object in your getter, in this case I do not think it would be good design to wrap it in a method. Especially if the wrapper is temporary and the COM object will be replaced later with managed code. It will keep your API consistent in the future without needing to change it.

Error checking omitted:

public class Wrapper {

    private COMObject _comObj;

    public Wrapper() {
        _comObj = [Create your Com Object here].
    }

    public string Name {
        get
        {
             return _comObj.getName();
        }    
    }
}

Answer 3

I like properties better for this case. you could even call a private "getName" function from within the property. Using get and set functions is something to avoid if all possible!

Answer 4

I'd go for:

• Cheap "get" (+"set") calls: properties
• Expensive "get" calls or only "set": methods

You see this thinking also back in the .NET Framework.

In you case it should be a method.

Answer 5

It also depends a lot on how big your COM object is and how expensive it is to create. If this is a one time deal you can decide to take the hit once and put the value you need in a backing store accessible via property.

In this case the answer is both use a method and use a property.

public class Foo
{
  private COMObject _ComObject;
  private string _Name;
  private COMObject GetComObject()
  {
    //Construct COMObject here
    // and return it
  }

  public string Name 
  {
    get
    {
      //Lazy load
      if (_ComObject == null)
      {
        _ComObject = GetComObject();
        _Name = _ComObject.getName();
      }
      return _Name;
    }    
  }
}