0

Let me be more specific by showing the following example:

public class Cat
{
   public string Name { get; set; }
   public string Color { get; set; }

   public Cat()
   {
       Cat("Unamed", "gray");
   }

   public Cat(string name, string color)
   {
       Name = name;
       Color = color;
   }

   public void SayMiau()
   {
       Console.WriteLine("Cat {0} says Miau!!!!!!!!!!", Name);
   }
}

In the SayMiau Method I use the property Name instead of using the field name as an argument inside the the class method.
Is there any difference?(computational cost?)
Is that considered a bad/good practice when I make method signatures for the same class?

strax
  • 283
  • 1
  • 3
  • 13
  • 2
    You are micro-optimizing things. Don't think about cpu cycles when you decide whether to use properties or fields. – Tim Schmelter Jun 01 '15 at 12:35
  • Your view makes sense but it`s curiosity mostly. – strax Jun 01 '15 at 12:47
  • 1
    As it makes no difference, please just replace your long-winded code with with something like https://gist.github.com/DavidArno/5d734dffe3a23f97781e. Except in edge-case situations, readability is always more important than trying to optimise. – David Arno Jun 01 '15 at 12:47
  • Thank you for the sample and I'm sorry for the code before, when i wrote it for the first time it wouldn't let me post it without comments. – strax Jun 01 '15 at 13:05

1 Answers1

3

When you read a property this is actually compiled as a call to a method.

Thus, this code:

 public void SayMiau()
 {
     Console.WriteLine("Cat {0} says Miau!!!!!!!!!!", Name);
 }

can be understood as this code:

 public void SayMiau()
 {
     Console.WriteLine("Cat {0} says Miau!!!!!!!!!!", get_Name());
 }

Note that the method name get_Name in there is not something you can call directly yourself, it is tagged as a special compiler-provided method for the property.

Method calls, however, are inlined if they are small, so since you only return the value of a backing field, by the time the JITter jit this code into native machine code, the call will likely be replaced with a direct read of the backing field.

However, in the future, if you change this property to have more calculation logic for its getter, that inlining will stop occurring, instead calling the method.

Now, having said all that, you can access the backing field directly but as a guideline I would use the property unless you have a good reason not to. Note that unless you put a lot of code into the getter, this is unlikely to be a performance bottleneck either way, but performance issues must be solved by other means than just tinkering, measure measure measure.

Lasse V. Karlsen
  • 380,855
  • 102
  • 628
  • 825
  • So the coclusion is that I should always use properties vs my hard coded data fields unless what u said in your last sentence must be done.Did i get this correct? – strax Jun 01 '15 at 12:45
  • 1
    Yes, as a guideline, use the property until you have a good reason not to. – Lasse V. Karlsen Jun 01 '15 at 12:50
  • Thank you so much, I am reading a book about C# and OOP and the example had the field instead of the property as argument which contradicted what I was reading so far.Thank you for the clarification and your in-depth explanation which ROCKS!!! . I wish I could give you more points. – strax Jun 01 '15 at 12:56