Getters、 setter 和属性的最佳实践

Regardless of which way you choose in C# the end result is the same. You will get a backinng variable with separate getter and setter methods. By using properties you are following best practices and so it's a matter of how verbose you want to get.

Personally I would choose auto-properties, the last version: public string Name { get; set; }, since they take up the least amount of space. And you can always expand these in the future if you need add something like validation.

Pre-C# 6

I'd use the last of these, for a trivial property. Note that I'd call this a public property as both the getters and setters are public.

Immutability is a bit of a pain with automatically implemented properties - you can't write an auto-property which only has a getter; the closest you can come is:

public string Foo { get; private set; }

which isn't really immutable... just immutable outside your class. So you may wish to use a real read-only property instead:

private readonly string foo;
public string Foo { get { return foo; } }

You definitely don't want to write getName() and setName(). In some cases it makes sense to write Get/Set methods rather than using properties, particularly if they could be expensive and you wish to emphasize that. However, you'd want to follow the .NET naming convention of PascalCase for methods, and you wouldn't want a trivial property like this to be implemented with normal methods anyway - a property is much more idiomatic here.

C# 6

Hooray, we finally have proper read-only automatically implemented properties:

// This can only be assigned to within the constructor
public string Foo { get; }

Likewise for read-only properties which do need to do some work, you can use member-bodied properties:

public double Area => height * width;

Use properties in C#, not get/set methods. They are there for your convenience and it is idiomatic.

As for your two C# examples, one is simply syntactic sugar for the other. Use the auto property if all you need is a simple wrapper around an instance variable, use the full version when you need to add logic in the getter and/or setter.

Whenever possible I prefer public string Name { get; set; } as it's terse and easily readable. However, there may be times when this one is necessary

private string name;


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

In C# favor properties for exposing private fields for get and/or set. The thie form you mention is an autoproperty where the get and set automatically generate a hidden pivot backing field for you.

I favor auto properties when possible but you should never do a set/get method pair in C#.

public string Name { get; set; }

This is simply a auto-implemented property, and is technically the same as a normal property. A backing field will be created when compiling.

All properties are eventually converted to functions, so the actual compiled implementation in the end is the same as you are used to in Java.

Use auto-implemented properties when you don't have to do specific operations on the backing field. Use a ordinary property otherwise. Use get and set functions when the operation has side effects or is computationally expensive, use properties otherwise.

As mentioned, all of these approaches result in the same outcome. The most important thing is that you pick a convention and stick with it. I prefer using the last two property examples.

In C# the preferred way is through properties rather than getX() and setX() methods. Also, note that C# does not require that properties have both a get and a set - you can have get-only properties and set-only properties.

public boolean MyProperty
{
get { return something; }
}


public boolean MyProperty
{
set { this.something = value; }
}

First let me try to explain what you wrote:

// private member -- not a property
private string name;


/// public method -- not a property
public void setName(string name) {
this.name = name;
}


/// public method -- not a property
public string getName() {
return this.name;
}


// yes it is property structure before .Net 3.0
private string name;
public string Name {
get { return name; }
set { name = value; }
}

This structure is also used nowadays but it is most suitable if you want to do some extra functionality, for instance when a value is set you can it to parse to capitalize it and save it in private member for alter internal use.

With .net framework 3.0

// this style is introduced, which is more common, and suppose to be best
public string Name { get; set; }


//You can more customize it
public string Name
{
get;
private set;    // means value could be set internally, and accessed through out
}

Wish you better luck in C#

If all you need is a variable to store some data:

public string Name { get; set; }

Want to make it appear read-only?

public string Name { get; private set; }

Or even better...

private readonly string _name;


...


public string Name { get { return _name; } }

Want to do some value checking before assigning the property?

public string Name
{
get { return m_name; }
set
{
if (value == null)
throw new ArgumentNullException("value");


m_name = value;
}
}

In general, the GetXyz() and SetXyz() are only used in certain cases, and you just have to use your gut on when it feels right. In general, I would say that I expect most get/set properties to not contain a lot of logic and have very few, if any, unexpected side effects. If reading a property value requires invoking a service or getting input from a user in order to build the object that I'm requesting, then I would wrap it into a method, and call it something like BuildXyz(), rather than GetXyz().

like most of the answers here, use Automatic properties. Intuitive, less lines of code and it is more clean. If you should serialize your class, mark the class [Serializable]/ with [DataConract] attribute. And if you are using [DataContract] mark the member with

[DataMember(Name="aMoreFriendlyName")]
public string Name { get; set; }

Private or public setter depends on your preference.

Also note that automatic properties require both getters and setters(public or private).

/*this is invalid*/
public string Name
{
get;
/* setter omitted to prove the point*/
}

Alternatively, if you only want get/set, create a backing field yourself

Which one should I use, and what are the caveats or subtleties involved with each approach?

When going with properties there is one caveat that has not been mentioned yet: With properties you cannot have any parametrization of your getters or setters.

For example imagine you want to retrieve a list items and want to also apply a filter at the same time. With a get-method you could write something like:

obj.getItems(filter);

In contrast, with a property you are forced to first return all items

obj.items

and then apply the filter in the next step or you have to add dedicated properties that expose items filtered by different criteria, which soon bloats your API:

obj.itemsFilteredByX
obj.itemsFilteredByY

What sometimes can be a nuisance is when you started with a property, e.g. obj.items and then later discovered that getter- or setter-parametrization is needed or would make things easier for the class-API user. You would now need to either rewrite your API and modify all those places in your code that access this property or find an alternative solution. In contrast, with a get-method, e.g. obj.getItems(), you can simply extend your method's signature to accept an optional "configuration" object e.g. obj.getItems(options) without having to rewrite all those places that call your method.

That being said, (auto-implemented) properties in C# are still very useful shortcuts (for the various reasons mentioned here) since most of the time parametrization may not be needed – but this caveat stands.