In VB.NET it is possible to do the following in a class.
Public Property MyProperty As String
At this point a getter and setter is automagically created for you and you can refer to variable defined by the property as such.
Me._MyProperty = "BlahBlah"
Is there an equivalent mechanism in C# ?
public string MyProperty {get; set;}
by default they are both public accessors, you can make one of them private like this:
public string MyProperty {get; private set;}
In C# you cannot refer to the underlying variable of auto implemented properties directly.
Related
Is it possible to have a C# class property
ie: public type name { get; set; }
whose value you can alter within the private member functions of the class, but which can only be read by a client program (externally only the 'get' function is available)?
Easy, use private:
public type name { get; private set; }
They are methods, just like any other (albeit with pre-defined signatures), so access modifiers still apply
I have this code:
public string foo { get; set; }
Now, I interpret this as my object has a public property called foo, and both it's accessor's are public. If I write this:
private string foo { get; set; }
I interpret that as my object has a private property called foo, and both it's accessor's are private. I understand making the property itself private. What I don't understand is why the accessor's must be more restrictive? If I write:
private string foo { public get; public set; }
I interpret that my object has a private property called foo, and both's it's accessor's are public, which is the behavior that I want. I'd like the private property with public accessors. I mean, if I have to write a Get/Set method, I will. But I'm just confused as to why this is.
A property is actually (under water) nothing more than two methods:
public string foo { get; set; }
will translate into:
public string get_foo() { ... }
public void set_foo(string value) { ... }
These methods can only have ONE access modifier, not a combination of two.
If I remember correcly, C#v1 did not support access modifiers for the getters and setters. There was one access modifers for the property which was used for both functions.
In v2 it was possible to "override" one of getter/setter-pair, this way overrwriting the "other" function. There was no use to override both getters/setters, because in that would render the property-access modifier useless.
Why the access modifier for the getter/setter is more restrictive has, in my opinion, something to do with easier implementing interfaces which always have (implicitly public) properties.
For more info, read: http://msdn.microsoft.com/en-us/library/75e8y5dd(v=vs.80).aspx
Why you need such a property
private string foo { public get; public set; }
If you want to have you get set public, then make the property public.
The compiler will first check the access of the property and then its method. If the property is public then its method can have either public or private or any accessor
My textbook is referring to the this reference and it first implies that a property is somewhat static and does not store one with each object, but one for the entire class. Then later it says that a property is nonstatic. I am really confused. What is it?
Properties can be static or not static.
Static properties have the 'static' keyword, default is not static.
Properties that are static are stored for the entire class (there is only one).
Properties that are not static are stored per instance.
A property can be both static and non-static you decide which by using the static keyword.
public static int StaticProperty {get; set; }
public int InstanceProperty {get; set; }
On a side note, a property is actually two methods (or just one if you only implement the set or get).
public int MyProperty {get; set; }
is equivalent to
public void set_MyProperty(int value);
public int get_MyProperty();
Why it is not ok to use IEnumerable<T> as a type for a property within a class
for instance something like
public class Example
{
public IEnumerable<Int32> Ids {get; private set;}
publicIEnumerable<string> Names {get; private set;}
}
Sorry the problem was not that it wasn't compiling, I missed the public accessors on writing the stuff here, the question was why not to use IEnumerable for a property. But as I read further, I realized that if we only need something to iterate through and not modify (add, remove) than this (using IEnumerable ) is perfectly acceptable.
The problem is that the default accessibility of members in classes is already private, so your code is equivalent to:
public class Example
{
private IEnumerable<int> Ids {get; private set;}
private IEnumerable<string> Names {get; private set;}
}
That fails to compile because when you include an extra access modifier for a getter or setter, it has to be more restrictive than the overall access of the property. It isn't in this case.
If you make the overall property public though, it will compile with no problems:
public class Example
{
public IEnumerable<int> Ids {get; private set;}
public IEnumerable<string> Names {get; private set;}
}
(That's assuming you have a using directive for the System.Collections.Generic namespace, of course.)
Take for example following code from a class:
public class Employee : IEntity
{
public string FirstName { get; set; }
public string LastName { get; set; }
public int EmployeeID { get; set; }
}
public class Company : IEntity
{
public string Name { get; set; }
public string TaxID { get; set }
}
I always used get; and set; with something in braces. I never left them like this.
Writing just:
get; set;
What it means?
Auto-Implemented Properties
In C# 3.0 and later, auto-implemented
properties make property-declaration
more concise when no additional logic
is required in the property accessors.
They also enable client code to create
objects. When you declare a property
as shown in the following example, the
compiler creates a private, anonymous
backing field that can only be
accessed through the property's get
and set accessors.
These are called Auto-Implemented Properties:
http://msdn.microsoft.com/en-us/library/bb384054.aspx
The compiler will generate a backing field, similar to this code:
public class Company : IEntity
{
public string Name
{
get { return _Name; }
set { _Name = value; }
}
private string _Name;
}
It was decided that this syntax could be made much shorter, but still keep all the same utility, hence Auto-Implemented Properties were born :)
Just look at it as an quick and easy C# way of giving you a read write permission over a variable.
One of the good things of C# if you ask me.
The other answers pretty much tell you everything else there is to know about auto get set.
Even though these two quotes seem somewhat conflicting:
CD said:
In C# 3.0 and later, auto-implemented
properties make property-declaration
more concise when no additional logic
is required in the property accessors.
They also enable client code to create
objects. When you declare a property
as shown in the following example, the
compiler creates a private, anonymous
backing field that can only be
accessed through the property's get
and set accessors.
While Merlyn Morgan-Graham said:
These are called Auto-Implemented
Properties:
http://msdn.microsoft.com/en-us/library/bb384054.aspx
The compiler will generate a backing
field, similar to this code:
public class Company : IEntity {
public string Name
{
get { return _Name; }
set { _Name = value; }
}
private string _Name; }
It was decided that this syntax could
be made much shorter, but still keep
all the same utility, hence
Auto-Implemented Properties were born
:)
To me that seems like CD said it does create a condition whilst Merlyn Morgan-Graham said there are none.
I think CD is correct when stating you can longer use , for example, the setters write permission as a response to also change whatever it's writing.
private int x = 3;
public int _x { get; set /*Change x*/; }
You would have to use the normal get set construction for that