I have this property in my Class:
public string A
{
set
{
A = value;
}
}
It gives me an error whenever I try to assign a value to A. Actually, my IIS Express stops and gives no clue.
I have a feeling that this creates an endless assignment of value to A, it's like a recursion. My questions:
What is happening in my code?
Is property just an accessor (getter/setter) and not a container when you specify an implementation?
When using auto-implemented property, is the property both container and accessor?
You'll have a StackOverflow exception, since you're assigning the property itself in its setter, which results in an endless assignment.
You can not set property variable itself as a container..
you can write like this.
Scenario 1:
public string A
{
set;
}
Scenario 2:
private string _A=String.Empty;
public string A
{
set{_A=value;}
}
let me know if any question.
When you are using an auto implemented property, the compiler generates a container for the value and methods to work with that container (get and set).
When you implement the propriety yourself, like you did, the compiler only generates a set method, that then calls itself, resulting in an endless loop. The correct way to do it would be:
private string _a;
public string A
{
set
{
_a = value;
}
}
In this case, the compiler will generate a method to set the value of _a , and no recursion occurs.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
In C# what does this code with “get” mean?
I'm using open source project. In this project there is function.
public virtual ICollection<Customer> AffiliatedCustomers
{
get
{
return _affiliatedCustomers ?? (_affiliatedCustomers = new List<Customer>());
}
protected set { _affiliatedCustomers = value; }
}
I don't understand what is the meaning of "get".
Can you please explain this function.
AffiliatedCustomers is a property.
The get defines the property getter, which is a method used internally to return the value by the property. It allows you to use this given an instance of the class like so:
var customers = theClass.AffiliatedCustomers; // Looks like a field, but is a property
Properties can also have a set section, as well, as this one does (protected set { _affiliatedCustomers = value; }), which gives you control over what happens when you set the value via the Property.
For details, see Properties in C#.
This is not a function. It is a property. A property is basically a fancy wrapper for some variable. For example, declaring the following property:
public string SomeProperty { get; set; }
will actually compile to something like this:
private string backing_SomeProperty;
public void set_SomeProperty(string value)
{
backing_SomeProperty = value;
}
public int get_SomeProperty()
{
return backing_SomeProperty;
}
That's an example of an automatic property. Of course, you can also define the getter and setter methods yourself like this:
public string SomeProperty
{
get
{
// some logic code here
// then return some value
}
set
{
// some logic code here
// then set some value
}
}
This is a property,
Quoted by msdn:
Properties are members that provide a flexible mechanism to read, write, or compute the values of private fields. Properties can be used as though they are public data members, but they are actually special methods called accessors. This enables data to be accessed easily while still providing the safety and flexibility of methods.
Please refer to this link for more:
http://msdn.microsoft.com/en-us/library/x9fsa0sw(v=vs.80).aspx
Properties have a getter and a setter - their purpose is obvious (to get and set the value of the property).
When you use auto properties, there is still a get and a set, but the backing variable is automatically implemented for you. In the example you have given the author of the code has chosen to have their own implementation of the get - in this case to automatically initialise the member variable the first time the property is accessed.
e.g.
[XmlAttribute("Type")]
public string DataTypeString
{
get
{
return _dataType.ToString();
}
set
{
_dataType = Type.GetType(value);
}
}
private Type _dataType;
public Type DataType
{
get { return _dataType; }
set { _dataType = value; }
}
In the above code, first property type is string, however the setter sets, the _dataType which is of System.Type
You can and often benificial to do so for get properties.
Type conversion in set properties likley be more contraversial. Properties are normally expected to be lightweight, not to throw exceptions and normally x.YYY=newValue; expected to result in x.YYY==newValue to be true - these may be hard to achieve if type conversion happens.
I.e. in your particular example allowing to set type by string as property feels like a bad idea - what is expected behavior of x.DataTypeString="42";? You may want to consider some other way to enable XML serialization of your property...
Sure you can. That's the purpose of the properties. The user of the property doesn't need to know what's behind it. He/she just sets or gets a string and that's all they need to know.
I guess its ok, but I would prefer to just do this, which less odd and less verbose:
public void SetDataType(string value) {
_dataType = Type.GetType(value);
}
public void SetDataType(Type value) {
_dataType = value;
}
public Type DataType { get; private set; }
As was already mentioned, it seems rather odd to have two getter/setter pairs for the same private variable.
It's hard to say without knowing the purpose of this class. But in general, I think I'd be confused by having two properties with the same backing field (so that changing one affects the other).
There are exceptions though. For example, in a Circle class, I would find it perfectly reasonable to have both a Radius property and a Diameter property. So again, it kind of depends on the purpose of your class.
Also, in the example you provided, it doesn't seem like the DataTypeString property provides much benefit. If you remove it, callers could achieve the same effect by simply calling
foo.DataType = Type.GetType("System.Int32");
or
string dataTypeString = foo.DataType.ToString()
.
why do we do this:
private string StatusText
{
set { toolStripStatusLabel1.Text = value; }
}
instead of just this?
private string StatusText
{
toolStripStatusLabel1.Text = value;
}
i do not understand the point of using set?
These are two completely different things.
This is a method:
private string StatusText()
{
toolStripStatusLabel1.Text = value;
}
which is called like this:
StatusText();
(and which will not compile, because the local variable value cannot be found). To make it work, you would need to write it like this:
private string StatusText(string value)
{
toolStripStatusLabel1.Text = value;
}
and call it like this:
StatusText("bla");
On the other hand, this is the definition of a property:
private string StatusText
{
set { toolStripStatusLabel1.Text = value; }
}
whose setter (hence the keyword set) is called like this:
StatusText = "bla";
Because there could also be a get:
get { return toolStripStatusLabel1.Text; }
Properties are syntactic sugar. When compiled you will have two methods get_[property name] and set_[property name]. If you only have the set method, only the set_[propety name] will be in the IL.
In a little more detail, since the OP has said she doesn't understand gets and sets:
The get and set keywords are used to define a "property". A property is a pair of methods - a "getter" and "setter" - that are used behind the scenes when the property is used or written to by other code. The advantage of a property over explicitly defining getter and setter methods is that you can use the property as if it were a "field" (a simple, publicly-visible member variable). The advantage of using a property instead of a field is that a property allows you to customize the behavior of assigning or using a variable. You can create "calculated fields" that are evaluated when needed based on other data in the object, or include basic validation or other business logic when reading or writing a value.
To define a property, you start by declaring it like you would a field, but then add a code block with get and set sub-blocks. You then define its read behavior in the get block, and the write behavior in the set block. You can choose to define only one accessor (making a "read-only" or "write-only" property), or you can define more limited visibility for one function or the other; for instance, you can make the getter public but the setter protected, so everyone can examine the property's value but only the class's other members and derived types can set its value.
The most common property implementation uses a "backing field", a private variable that acts as the store for the value exposed by the property. To streamline this implementation, .NET 3.0 included the concept of an "auto-property"; if you didn't define the code bodies of the getter and setter, the compiler would generate a basic implementation using a backing field.
First will not compile for value isn't valid unless you have set.
private string StatusText
{
toolStripStatusLabel1.Text = value;
}
Check out MSDN on Accessors here.
Setting and Getting fields and properties...
Example:
private string statusText;
public string StatusText
{
get { return this.statusText;}
set { this.statusText = value;
toolStripStatusLabel1.Text = this.statusText;
}
}
private String StatusText
{
get { ... }
set { ... }
}
The get/set tokens are to distinguish between the get and set accessors.
The latter wouldn't compile. The set part shows that it's the setter part of a property.
An alternative is to just write a method:
private void SetStatusText(string value)
{
toolStripStatusLabel1.Text = value;
}
To enable you to apply more complex logic, when the need will arise.
Sometimes you have a private field that backs a property, you only ever want to set the field via the property setter so that additional processing can be done whenever the field changes. The problem is that it's still easy to accidentally bypass the property setter from within other methods of the same class and not notice that you've done so. Is there a way in C# to work around this or a general design principle to avoid it?
IMHO, it is not used, because:
The class must trust itself
If your class gets as large that one part does not know the other, it should be divided.
If the logic behind the property is slightly more complex, consider to encapsulate it in an own type.
I'd consider this a nasty hack and try to avoid it if possible, but...
You can mark the backing field as obsolete so that the compiler will generate a warning when you try to access it, and then suppress that warning for the property getter/setter.
The warning codes that you'd need to suppress are CS0612 for the plain Obsolete attribute and CS0618 if the attribute has a custom message.
[Obsolete("Please don't touch the backing field!")]
private int _backingField;
public int YourProperty
{
#pragma warning disable 612, 618
get { return _backingField; }
set { _backingField = value; }
#pragma warning restore 612, 618
}
There's no inbuilt way to do what you want to do, but by the sounds of things you need another layer of abstraction between your class and that value.
Create a separate class and put the item in there, then your outer class contains the new class, and you can only access it through its properties.
No, there isn't. I'd quite like this myself - something along the lines of:
public string Name
{
private string name; // Only accessible within the property
get { return name; /* Extra processing here */ }
set { name = value; /* Extra processing here */ }
}
I think I first suggested this about 5 years ago on the C# newsgroups... I don't expect to ever see it happen though.
There are various wrinkles to consider around serialization etc, but I still think it would be nice. I'd rather have automatically implemented readonly properties first though...
You CAN do this, by using a closure over a local in the constructor (or other initialisation function). But it requires significantly more work that the helper class approach.
class MyClass {
private Func<Foo> reallyPrivateFieldGetter;
private Action<Foo> reallyPrivateFieldSetter;
private Foo ReallyPrivateBackingFieldProperty {
get { return reallyPrivateFieldGetter(); }
set { reallyPrivateFieldSetter(value); }
}
public MyClass() {
Foo reallyPrivateField = 0;
reallyPrivateFieldGetter = () => { return reallyPrivateField; }
reallyPrivateFieldSetter = v => { reallyPrivateField = v; };
}
}
I suspect that the underlying field type Foo will need to be a reference class, so the two closures are created over the same object.
There is no such provisioning in C#.
However I would name private variables differently (e.g. m_something or just _something) so it is easier to spot it when it is used.
You can put all of your private fields into a nested class and expose them via public properties. Then within your class, you instantiate that nested class and use it. This way those private fields are not accessible as they would have been if they were part of your main class.
public class A
{
class FieldsForA
{
private int number;
public int Number
{
get
{
//TODO: Extra logic.
return number;
}
set
{
//TODO: Extra logic.
number = value;
}
}
}
FieldsForA fields = new FieldsForA();
public int Number
{
get{ return fields.Number;}
set{ fields.Number = value;}
}
}
It just provides a level of obstruction. The underlying problem of accessing private backing fields is still there within the nested class. However, the code within class A can't access those private fields of nested class FieldForA. It has to go through the public properties.
Perhaps a property backing store, similar to the way WPF stores properties?
So, you could have:
Dictionary<string,object> mPropertyBackingStore = new Dictionary<string,object> ();
public PropertyThing MyPropertyThing
{
get { return mPropertyBackingStore["MyPropertyThing"] as PropertyThing; }
set { mPropertyBackingStore["MyPropertyThing"] = value; }
}
You can do all the pre-processing you want now, safe in the knowledge that if anyone did access the variable directly, it would have been really really hard compared to the property accessor.
P.S. You may even be able to use the dependency property infrastructure from WPF...
P.P.S. This is obviously going to incur the cost of casting, but it depends on your needs - if performance is critical, perhaps this isn't the solution for you.
P.P.P.S Don't forget to initialise the backing store! (;
EDIT:
In fact, if you change the value property stored to a property storage object (using the Command pattern for example), you could do your processing in the command object...just a thought.
Can't do this in standard C#, however you could
define a custom attribute say OnlyAccessFromProperty
write your code like
[OnlyAccessFromProperty(Name)]
String name
Name
{
get{return name;}
}
etc …
Then write a custom rule for FxCop (or another checker)
Add FxCop to your build system so if your custom rule find an error the build is failed.
Do we need a set of standard custom rules/attributes to enforce common design patens like this without the need to extend C#
C# has no language feature for this. However, you can rely on naming conventions, similar to languages which have no private properties at all. Prefix your more private variable names with _p_, and you'll be pretty sure that you don't type it accidentally.
I don't know C# but in Java you may have a base class with only private instance variables and public setters and getters (should return a copy of the instance var.) and do all other in an inherited class.
A "general design principle" would be "use inheritance".
There is no build in solution in C#, but I think your problem can be solved by good OO design:
Each class should have a single purpose. So try to extract the logic around your field into a class as small as possible. This reduces the code where you can access the field by accident. If you do such errors by accident, your class is probably to big.
Often interface are good to restrict access to only a certain "subset" of an object. If that's appropriate for your case depends on your setting of course. More details about the work to be done would help to provide a better answer.
You say that you do additional processing. Presumably this would be detectable under the correct conditions. My solution, then, would be to create unit tests that implement conditions such that if the backing field is used directly the test will fail. Using these tests you should be able to ensure that your code correctly uses the property interface as long as the tests pass.
This has the benefit that you don't need to compromise your design. You get the safety of the unit tests to ensure that you don't accidently make breaking changes and you capture the understanding of how the class works so that others who come along later can read your tests as "documentation."
Wrap it in a class? The property thing is a bit like that anyway, associating data with methods - the "Encapsulation" they used to rave about...
class MyInt
{
private int n;
public static implicit operator MyInt(int v) // Set
{
MyInt tmp = new MyInt();
tmp.n = v;
return tmp;
}
public static implicit operator int(MyInt v) // Get
{
return v.n;
}
}
class MyClass
{
private MyInt myint;
public void func()
{
myint = 5;
myint.n = 2; // Can't do this.
myint = myint + 5 * 4; // Works just like an int.
}
}
I'm sure I'm missing something? It seems too normal...
BTW I do like the closures one, superbly mad.
My favorite solution to this (and what I follow) is to name private backing fields that are never intended to be used directly with a leading underscore, and private fields that are intended to be used without the underscore (but still lowercase).
I hate typing the underscore, so if I ever start to access a variable that starts with the underscore, I know somethings wrong - I'm not supposed to be directly accessing that variable. Obviously, this approach still doesn't ultimately stop you from accessing that field, but as you can see from the other answers, any approach that does is a work around and/or hardly practical.
Another benefit of using the underscore notation is that when you use the dropdown box to browse your class, it puts all of your private, never-to-be-used backing fields all in one place at the top of the list, instead of allowing them to be mixed in with their respective properties.
As a design practice, you could use a naming convention for "private properties" that's different from normal public members - for instance, using m_ItemName for private items instead of ItemName for public ones.
If you're using the C# 3.0 compiler you can define properties which have compiler-generated backing fields like this:
public int MyInt { get; set; }
That will mean there is only one way to access the property, sure it doesn't mean you can only access the field but it does mean that there's nothing but the property to access.
I agree with the general rule that the class should trust itself (and by inference anybody coding within the class).
It is a shame that the field is exposed via intellisense.
Sadly placing [EditorBrowsable(EditorBrowsableState.Never)] does not work within that class (or indeed the assembly(1))
In Visual C#, EditorBrowsableAttribute does not suppress members from a class in the same assembly.
If you really do wish to solve this aspect of it the the following class may be useful and makes the intent clear as well.
public sealed class TriggerField<T>
{
private T data;
///<summary>raised *after* the value changes, (old, new)</summary>
public event Action<T,T> OnSet;
public TriggerField() { }
///<summary>the initial value does NOT trigger the onSet</summary>
public TriggerField(T initial) { this.data=initial; }
public TriggerField(Action<T,T> onSet) { this.OnSet += onSet; }
///<summary>the initial value does NOT trigger the onSet</summary>
public TriggerField(Action<T,T> onSet, T initial) : this(onSet)
{
this.data=initial;
}
public T Value
{
get { return this.data;}
set
{
var old = this.data;
this.data = value;
if (this.OnSet != null)
this.OnSet(old, value);
}
}
}
Allowing you to (somewhat verbosely) use it like so:
public class Foo
{
private readonly TriggerField<string> flibble = new TriggerField<string>();
private int versionCount = 0;
public Foo()
{
flibble.OnSet += (old,current) => this.versionCount++;
}
public string Flibble
{
get { return this.flibble.Value; }
set { this.flibble.Value = value; }
}
}
alternatively you can go for a less verbose option but accessing Flibble is by the not idiomatic bar.Flibble.Value = "x"; which would be problematic in reflective scenarios
public class Bar
{
public readonly TriggerField<string> Flibble;
private int versionCount = 0;
public Bar()
{
Flibble = new TriggerField<string>((old,current) => this.versionCount++);
}
}
or solution if you look at the community content!
The new Lazy class in .net 4.0
provides support for several common
patterns of lazy initialization
In my experience this is the most common reason I wish to wrap a field in a private properly, so solves a common case nicely. (If you are not using .Net 4 yet you can just create your own “Lazy” class with the same API as the .Net 4 version.)
See this and this and this for details of using the Lazy class.
Use the "veryprivate" construct type
Example:
veryprivate void YourMethod()
{
// code here
}