Develop Reference

Within the Containing Class, Use Property or Field?

Is it good practice to use the private field, or the property, when writing code in the class that contains them?
For example, if I have this field/property pair, classes outside this class must use the property. What about code inside the class? Should it use the private field, or should it also go through the property?
private string _foo;
protected string Foo
{
get { return this._foo; }
}
private void SomeMethod()
{
string dummyVariable = "snuh" + this._foo; // So, this...
string dummyVariable = "snuh" + this.Foo; // ... or this?
}
One advantage of using the property here, is if there is any logic in the getter, it will still get executed. I'm curious to know if there is a best-practice policy to follow here.

When using Auto-Implemented properties, you don't have a choice - you must use the property, as you don't have any access to the generated field.
If you property is not simple and does some extra work (validation, firing events etc...), you should call the property in order to centralize access and logic.
If you have any other properties (meaning a simple property with no logic and a backing field) I would ask why are they not one of the above...
With the example you have give, it makes little difference - it is more important to be consistent with how you use these and really boils down to personal aesthetics and coding style.

Why do we use blank get; set; accessors in C#? [duplicate]

This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
c#: why have empty get set properties instead of using a public member variable?
string name;
vs
string name {get; set;}
Assuming your get and set are blank as above, what's the point in specifying them?

It encapsulates the compiler generated field, and provides you, the class or struct developer the ability to update it internally later without breaking your API by simply modifying the get/set part that you care about.
For instance, suddenly never want to return null? You can do that by simply changing the empty get to get { return storedName ?? ""; }. Of course, it means you suddenly need to manually control the variable, but that's a small price to pay for the flexibility.
The first use is an example of a field declaration. The second use is an example of an auto-implemented property.
It is generally bad practice to provide direct access to a field. However, the .NET team noticed that a lot of getters/setters are basically just that. For example, consider the following:
// C#
public string Name
{
get { return name; }
set { name = value; }
}
// Without properties (or a Java implementation)
public void setName(String name)
{
this.name = name;
}
public String getName()
{
return name;
}
Either way, that's a lot verbosity to really just expose a field. However, it is regularly the case that, as a developer, you need to go back and change how a field is handled internally, but you do not want to break or even affect other code if you can get away with it.
That is why using direct access to fields is bad. If you provide direct access to fields, but need to change something about using the field, then all code that uses that field must change as well. If you use a property (or even a method), then you can change the internal code and potentially not effect external code.
Consider the following example:
public string Name
{
get;
set;
}
Later you decide that you need to raise a changing and changed event around the setter. If you exposed a field, then it's time for a potentially big rewrite. If you used properties (or a method), then you can just add the logic there. You suddenly lose the benefit of auto-implementing properties, but you gained the ability to refactor your class without breaking existing code.
private string name;
public event NameChangingEventHandler NameChanging;
public event NameChangedEventHandler NameChanged;
public string Name
{
get { return name; }
set
{
OnNameChanging(/*...*/);
name = value;
OnNameChanged(/*...*/);
}
}
protected virtual void OnNameChanging(/*...*/) { }
protected virtual void OnNameChanged(/*...*/) { }
All of that maintains your public API and requires no work from users of the class (the rest of your code, or external developers using of your API). Breaking changes are not always avoidable, but avoiding direct access to fields is a good step to try to ensure that it won't happen. Auto-implemented properties are a quick, and easy way to do it.
(Unrelated: lost power while typing this and I am very happy that my browser saved most of it!)

The first one is actually a Field, but the second one is an Auto-Implemented property. The difference between them has already been discussed.

The first, assuming it's declared in class scope, is a field name. It's accessed as a field. The second is a property. A Blank get/set is known as an auto-property.

You might need to actually do something in your accessors in the future. Changing a field (which is what your first declaration is) to a property is a breaking change, so specifying accessors in advance is a small investment in the future.

Being able to add logic to a field's accessors without breaking compatibility is the standard explanation, and it's certainly a big one if you're writing a library or an application that's split among several assemblies that might be updated independently. I think it's something that one could dismiss as less of a concern if you're working on any sort of "all-in-one" software, though, since it'll all be recompiled anyway.
But even then, there's still another very compelling reason to only expose properties in your public interfaces: Even if you never need to make any internal updates, using fields can still lead to other problems on down the line because many portions of the .NET framework strongly prefer properties to fields. WPF, for example, does not generally support binding to fields. You can get around that by doing fancy things like implementing ICustomTypeDescriptor, but it's just so much easier to simply type {get; set;}.

string name {get; set;}
This is called auto implemented property. Actually, C# creates variable starting with _ itself, so on get, that variable value is fetched and on set, that variable value is set. Its just like normal properties. Where as string name; is just a field.

The first is a variable, the second is a (shorthanded) property

Properties are very nice, but as a general rule, objects shouldn't expose state to the public; they should be a black box from the perspective of outsiders. And you especially shouldn't state to direct change. State should change as a side effect of asking the object instance to do something useful in the problem domain.
If you are going to expose state, expose it as a read-only property (e.g. public widget Foo { get ; private set ; }).

when and why to use C# accessor methods [duplicate]

This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
C# - When to use properties instead of functions
I am trying to understand when and why to use "getters" and "setters"
would someone please provide some guidance.
What is the difference between the following constructs - please look in terms of accessor methods only.
//EXAMPLE 1: simple accessor method
private static bool _isInitialEditMapPageLoad;
public static bool isInitialEditMapPageLoad
{
get {return _isInitialEditMapPageLoad;}
set {_isInitialEditMapPageLoad = value;}
}
//EXAMPLE 2: accessor method with a conditional test
private static bool _isInitialEditMapPageLoad;
public static bool isInitialEditMapPageLoad
{
get
{
if (currentSession[isAuthorizedUseder] == null)
return false;
else
return _isInitialEditMapPageLoad;
}
set {isInitialEditMapPageLoad = value;}
}
//EXAMPLE 3: just a get accessor method - is this the same as EXAMPLE 4?
private static bool _isInitialEditMapPageLoad = false;
public static bool isInitialEditMapPageLoad
{
get {return _isInitialEditMapPageLoad;}
}
//EXAMPLE 4: simple method
private static bool _isInitialEditMapPageLoad = false;
public static bool isInitialEditMapPageLoad
{
return _isInitialEditMapPageLoad;
}

Your getters/setters should be your public interface to your class.
As a rule of thumb, all of your members should be private except for what you want people to have access to outside of your class and you never want your private variables to be directly accessible outside if your class
Here's a simple example. say you had a class that you needed an age variable for. In this case, you could perform validation right there in the setter without your external classes needing to know that the value is validated.
class Person {
int age = 0;
public int Age {
get { return age; }
set {
//do validation
if (valid) {
age = value;
}
//Error conditions if you want them.
}
}
//More getters/setters
}

The reasoning behind Getters/Setters is to protect the class from being broken when a user alters a field in an invalid way, and they allow you to change the implementation of your class while leaving the publicly exposed properties unchanged.
Unless you need some kind of validation or lazy-loaded properties then you can usually just use auto properties.
public string Name { get; set; }

1: This is a simple property, and can be used in much the same way as a public field. If you have a reason to expose both get and set operations to other users (that is, other classes) and you don't need anything fancy, this is it. This can also be written with "auto-properties",
public static bool isInitialEditMapPageLoad {get;set;} // behaves just like example 1
auto props are much faster to write and in my opinion are much more readable than the full declaration (if I see a full declaration with a backing field, I expect to find some complexity).
2: This shows one of the reasons for properties: using some logic to return a value rather than always returning a value directly. Somebody can set this value as they would a public field whenever they want. They can get the value whenever they want, as well, with the caveat that false means either this isn't the initial load OR the user isn't authorized -- that is, some (simple) logic is done before returning a value.
3: This behaves as a public field ONLY for reading -- somebody can retrieve the value, but not set it. This is in essence a value that is read only to outside code (not to be confused with the readonly keyword)
4: Resulted in a compilation error for me. Assuming that is supposed to be a method declaration, manually defining a getter like one would do in Java, then it is similar to example 3. I believe there are other issues that make this not quite the same, like if you want to turn this into a dependency property, etc. Unfortunately my knowledge in that area comes up short.
==========
As a general rule, user properties to limit access to your class data. As a principle, anything that you can keep from allowing other code to touch, should be kept that way. As a practical matter, you will want to be able to set values on classes to change how they display, modify the data represented, et cetera. Use properties to maintain maximum control of this interaction.
If other classes will need to view something in your class, you'll need to expose a getter, but not a setter. This isn't possible with fields, unless you use the Java method of writing a custom getter method. They also allow you to perform calculations or validations before returning or setting data. For example, if you have some integer value that should be within some range (a range which can change depending on the state of your object, even), in your setter you can check to make sure this condition is met before actually updating your value.
Try to avoid the trap of just setting everything as an autoprop -- this is no different than making everything a public field. Keep everything as private as possible. No getters unless necessary, no setters unless necessary, and setters should perform any small logic necessary to verify input before accepting it, if appropriate. That said, avoid the other trap: putting lots of code in getters/setters. If it takes more than a handful of lines, you should probably make a method rather than a property, simply because it gives a greater hint to others using your code that something big is going to happen.

Like others mentioned, use getters/setters when you want the object members to be available to other objects.
Additionally, the readability of yoru code could be improved (if you're on .NET 2.0 or greater) using autoproperties. The examples you have would then be like this:
// example 1
public static bool IsInitialEditMapPageLoad { get; set; }
// example 3/4 - note that false is the default for bools
public static bool IsInitialEditMapPageLoad { get; private set; }
Example 3 would likely stay the same, due to the validation logic being there.

Overloading properties in C#

Ok, I know that property overloading is not supported in C# - most of the references explain it by citing the single-method-different-returntype problem. However, what about setters? I'd like to directly assign a value as either a string or object, but only return as a string.
Like this:
public string FieldIdList
{
get { return fieldIdList.ToString(); }
set { fieldIdList = new FieldIdList(value); }
}
public FieldIdList FieldIdList
{
set { fieldIdList = value; }
}
private FieldIdList fieldIdList;
Why wouldn't this be allowed? I've also seen that "properties" simply create getter/setter functions on compile. Would it be possible to create my own? Something like:
public void set_FieldIdList(FieldIdList value)
{
fieldIdList = value;
}
That would do the same thing. Thoughts?

Properties are in fact a pair of get/set methods (one of which may be left out), but the property itself has additional metadata which makes it a property in the first place instead of just two methods.
Because the property signature remains invalid as per only-different-by-return-type, even if you only have a setter. If you need this, don't use a property; set-only properties aren't a good thing anyways.

One approach (you may argue amongst yourselves as to whether this is a good design choice or not) is to add a second property, which accesses the data in a different form.
However, as it is going to be parsing the string (doing significant work), it would be better not to use a property for this, but to add methods that allow you to get/set the data in a string form.
I'd go for fieldIdList providing ToString() and TryParse() interfaces - then if you need it as a string, you'd call myObject.FieldIdList.ToString() etc. This encapsulates everything tidily, allows you to convert to/from string formats anywhere in your code rather than only when accessing FieldIdLists as a member of some other class, and makes the client code really clear and easy to understand.

If you want to be able to set a property as either a string or an object then you would just use object as the type of the property, since it's the base class (you can pass a string to a property that accepts an object). This doesn't seem particularly good design decision, but it can be done. Perhaps you need to explain further what you are trying to achieve?

You cannot overload C# properties as of C#7.
However, a redesign including your property is possible.
You can use a condition in your set block to call a private function,
which can be overloaded.
public string FieldIdList
{
get { return fieldIdList.ToString(); }
set { fieldIdList = ChangeFieldList(value); }
}
private string ChangeFieldIdList(int i) {
return i.ToString();
}
This example is just mean't to show a redesign consideration using private functions
to be called within the set block.

Do you use Data Members or Public Properties from within the Class itself?

If I have a simple class setup like this:
class MyClass
{
private string _myName = string.Empty;
public string MyName
{
get
{
return _myName;
}
}
public void DoSomething()
{
// Get the name...
string name = string.Empty;
name = _myName;
// OR
name = MyName;
// ...and do something with it...
}
}
Which should I use, the public property, or the data member?
Obviously, in this example it doesn't make a difference, since they both just reference the same variable. But what about real world uses of Public Properties?
In general, do Public Properties perform very little, in which case it is OK to call them? Or do people put a lot of functionality into their Public Properties that should not be called by internal class references?
I saw something in another post about NOT putting lots of functionality into Properties, since examining them in the Debugger can perform unexpected results. Is that true?

Use the property - any logic that may be encapsulated within the setters and getters ought to apply, even within the class itself. If there is no logic within the getters and setters it is still not safe to use the fields themselves because if at any point you wish to add logic around the access to those fields you will have to refactor much more.

I believe that you should reference the property as a general practice. While in this particular example it really doesn't make much of a difference, the get/set accessors offer the ability to do a bit more work when grabbing a property. For example, many of our property "get" accessors perform some lookup within a more complex data structure or set default values if nothing has been defined. So that the rest of the class can take advantage of this logic, we make a habit of using the properties. Just so we don't have to think too hard about it, we try to generalize the practice.
There may be instances in which we want to directly access the underlying data member, but then that is a conscious decision with a specific reason and it tends to be the exception.

I prefer properties because they easily handle read-only situations and it's easy to wrap them with any basic validation you might need to do.

If I'm just returning the value of the internal variable, I make the variable public - there's no harm to doing so. I've always used Public Properties when I want to do something in response to either a viewing or a changing of the value - ie, write it to a database, set something else too (as in the second part of your example).
The question you have to ask is whether you want what happens inside your class to trigger these events. If you do, the same way an external caller would, then access the values via the property. If you just want to read the value, use the internal variable.
To answer your question, there's no harm to doing it either way - just consideration of the potential side-effects.