2

I've been looking into C# Properties, and I'm a little confused over what you gain by some suggested examples, such as Microsoft's.

Their class property example is as follows:

public class SaleItem
{
   string name;
   decimal cost;

   public SaleItem(string name, decimal cost)
   {
      this.name = name;
      this.cost = cost;
   }

   public string Name 
   {
      get => name;
      set => name = value;
   }

   public decimal Price
   {
      get => cost;
      set => cost = value; 
   }
}

What does their example give you, over declaring your class properties such as:

public class SaleItem
{
   public string Name { get; set; };
   public decimal Cost { get; set; };

   public SaleItem(string name, decimal cost)
   {
      Name = name;
      Cost = cost;
   }
}

I think the usage of this and => is throwing me off, as I'm not too familiar with them, but I generally dont understand what the difference is between these two examples, or why you might choose one over the other.

Apologies if this is too general a topic, but anyone can clarify any maybe point me in the direction of some useful resources, it would be appreciated.

devklick
  • 2,000
  • 3
  • 30
  • 47
  • 1
    Possible duplicate of [What are Automatic Properties in C# and what is their purpose?](https://stackoverflow.com/questions/6001917/what-are-automatic-properties-in-c-sharp-and-what-is-their-purpose) – gunr2171 Nov 08 '18 at 18:35
  • And also [What is the => assignment in C# in a property signature](https://stackoverflow.com/questions/31764532/what-is-the-assignment-in-c-sharp-in-a-property-signature) – gunr2171 Nov 08 '18 at 18:36
  • [According to C# Labs, they are (almost) the same.](https://sharplab.io/#v2:CYLg1APgAgzABFATHAygQwDYFMCSAXLAWwEYBYAKAG8K5apiAGOAOzUKwG4bbgsBjAJaFMcPgHsAzni7luCeOmz4ixABT0mrdgBo4vQcIyjJeAJRzq5Wtbh4AFgIkA6LVjgBeFm05zr9x07iUh7GUjLWAL4UcrAIjHAAct5wFr60AOZYeB4AfF7s4TZwElm5+W6eAG6YAK4+VrRRsg3yevxCIgAKAE4CfFipLdaZ2e55QdJpxaVjoaNw1Rh1HCktTU3R5LFIqJi4BISIFJbW2/FJ7HCUcCMrJdJwTafw+h1GAMImVzdZd7+Pm2euyUB0Q6nirl0r0Mc3MLRORQuFXKhRsn2CngmqPWQA) – Zohar Peled Nov 08 '18 at 18:37

2 Answers2

0

The this keyword is used for the current instance of the class. With this approach you can access members from within constructors, instance methods, and instance accessors.

this keyword is used when you want to refer to a instance. Ans then can be invoked to perform some calculation related with that instance.

By using auto-implemented properties, you can simplify your code while having the C# compiler transparently provide the backing field for you.

public string Name { get; set; };
public decimal Cost { get; set; }

Properties can be written with a simple lambda syntax, instead of having to write a full body

public string Name 
   {
      get => name;
      set => name = value;
   }

Expression-bodied are added to improve properties declaration. Instead of statement blocks it’s now possible to define body as lambda expression. The syntax is quite easy to use =>.

Llazar
  • 3,167
  • 3
  • 17
  • 24
0

In example 1 you actually get to code out your Properties with relatively little effort. While example 2 is Auto-Implement ones.

I generally prefer Auto-Implement Properties (case 2). Actually implementing any logic is secondary to me. I generally use Proeprties and Auto-implement ones are the shortest way to write them. I avoid fields entirely nowadays.

I do not see any advantage in case 1. It might be their way to showcase some new mechanics. Some way to code out properties without all that Bracket overhead. It looks like Lambda, but someone else mentioned it is not.

If anything I have to critizise cas 1. One of the biggest dangers of Properties is to accidentally use the backing fields in class code. That should never happen. And having the the backing fields just lower case is not a viable way to avoid it. Indeed Micrsoft own standart is to start backing fields with a underscore "_" so there is no mixups.

"name" and "Name"? Easy to mix up. I can not remember how often I typed to fast and a uppercase starting letter was not recognised.

"_Name" and "Name"? A heck of a lot harder to mix up and instantly visible if you do.

Christopher
  • 9,634
  • 2
  • 17
  • 31
  • @DanielSiebert: That makes no sense. As I said - both here and on the linked article - it is fundamentally import to **never** mix up Backing Fields and Property. with name/Name, it can literally happen by accident. With _Name/Name, it is impossible. If the property is public or private does not mater for that. In either case a mixup would be a critical mistake. If anything mixing it up with Public ones is worse. Because those Properties are there to do some stuff on value changes. I lost count of how often people made that mistake. – Christopher Nov 08 '18 at 19:12