0

First just to clarify and avoid unnecessary duplicate tagging, this question is not a duplicate of this one, neither a duplicate of this other one or others I have already searched. Why? they all talk about public fields or private fields WITH the classical C#'s "properties".

My question is why should I write something like this (Public Properties)

class myClass{

public int AValue{get; set;}
}

when I can write instead (Private fields without any properties involved) (Just classic old C++ style way of writing things)

class myClass{
private int aValue;
public int getValue{ return aValue;}
public void setValue(int value){ aValue=value;}

I am scratching my head, reading many many resources, answers and questions, and no one of them answer this question. They all talk about the advantages over public fiels (which I am not asking about) or about the advantages of the new automatic properties over the old ones (which I am not asking either).

I guess my question is why C# does not use the same way of writing that has worked well in Java or C++ that works well. I don't see any advantage. I would very much appreciate someone teaches me the advantage because afaik is not written anywhere else. (not even in my C# books)

KansaiRobot
  • 7,564
  • 11
  • 71
  • 150
  • I'd suggest that Properties are more elegant and intuitive than creating your own propriety methods to accomplish the exact same thing. Writing code that is standard for the development platform helps make it easier to maintain. However all of this is just my opinion. There can be no universally correct answer to this question as any answer will be primarily opinion based. Which makes this question off-topic. – Mick Jul 06 '17 at 05:06
  • 1
    Consider to read this: https://stackoverflow.com/questions/22900456/in-regards-to-the-difference-between-java-properties-and-c-properties. In short, C# properties influenced from VB which is a syntactic sugar to save keystrokes & avoid typing "getX" & "setX" often like Java or C++ does. – Tetsuya Yamamoto Jul 06 '17 at 05:13

6 Answers6

0

From my understanding the public properties that you are referring to are merely syntactic sugar wrapping the pattern that you describe above.

It comes down to readablity and platform standards I guess. While there is nothing wrong with the way that you are talking about, we also need to consider maintainability. To another .Net developer, that pattern does not fit what they are used to and could cause confusion.

And the there is the superficial reason, it is just a lot more code to write. Especially when you have something like a DTO.

David Pilkington
  • 13,528
  • 3
  • 41
  • 73
  • I think C# properties pretty much influenced from how VB properties defined, which includes accessor (`Property Get`) & mutator (`Property Let/Set`) with a backing field (example: https://stackoverflow.com/questions/31448603/why-would-one-declare-both-a-let-and-set-property-accessor-in-vb6). In fact, there is a `value` variable which serves as backing field in C# properties, like VB counterpart. – Tetsuya Yamamoto Jul 06 '17 at 05:03
0

The properties in c# are further encapsulated and eventually translated into an intermediate language of a private field and the corresponding Get Set method, so you don't have to be bothered

luyee
  • 1
  • 2
0

Auto-accessors are syntactical sugar for exactly that. The generated code has a backing field and get/set methods. Fields don't have accessors, whereas properties do.

Public/private is about encapsulation/security, i.e. who should be able to access your information.

AndrewP
  • 1,598
  • 13
  • 24
0

In the way you presented it (writing get and set method) is good, but you have two methods - one for setting the value of the field and one for getting this value. Using properties, it's more natural to me, since you "encapsulate" set and get method under one name and accessing it is better this way (in my opinion).

Michał Turczyn
  • 32,028
  • 14
  • 47
  • 69
0

The main reason for using public int AValue { get; set; } instead of a private field and a getAValue and setAValue pair of functions is that that's just the way that things are done in C#. From a "what the code does at runtime" perspective, the two are pretty much the same as an "auto property" (the type of property you've got where you let the compiler take care of generating a private backing field) compiles down into code very similar to that which you've written (see this stackoverflow questions accepted answer for an example).

The main "advantage" in the context of your question (why use a property instead of a field and a get/set pair of methods) is predictability and comprehensibility. Anyone who's working with your code will expect to see properties, rather than a private field/get/set implementation and thus your code will be more immediately comprehensible to them. Seeing it implemented differently will cause them to question why, assume that there's a reason for it and thus slow them down when it comes to understanding your code.

Rob
  • 45,296
  • 24
  • 122
  • 150
0

C#'s getter and setter is syntactic sugar, which remove noisy method names (SetValue or GetValue vs just Value) and increase readability of the code.

Readability is much better in consuming code

// Without properties
var myClass = new MyClass();
myClass.SetAValue(aValue);
myClass.SetBValue(bValue);

//And with properties
var myClass = new MyClass 
{
    AValue = aValue,
    BValue = bValue
}

Because it is only syntactic sugar - every developer/team are free to not use it.
Some teams have "rules" that properties should be used only for getting/setting values without any "heavy" logic in getters/setters. And methods should be used for setting or getting values which executes some "heavy" operations.

Fabio
  • 31,528
  • 4
  • 33
  • 72