Below, when I attempt to use the _currentTemp variable, that was supposed to be auto-generated via the auto properties functionality, I get a variable not found message:
The name _currentTemp does not exist in the current context.
Using { get; set; } should automatically create this private variable (_currentTemp), right?
public class DogTemperature
{
public double CurrentTemp { get; set; }
public DogTemperature(double dCurrentTemp)
{
_currentTemp = dCurrentTemp; //***this line***
}
}
Backing fields created by auto-properties are not available for you to interact with in your source code, as it is generated by the compiler.
If you want to interact with the backing field, you'll need to create your properties the verbose way.
In my opinion defining a property like this is complely pointless if all you want to do is store a value.
double _currentTemp;
public double CurrentTemp
{
get { return _currentTemp; }
set { _currentTemp = value; }
}
All you're doing here is giving the private context two ways to set the same value. You can set the _currentTemp field directly or you can set the CurrentTemp property which sets the _currentTemp field. If you are not doing anything with the property then just use the default get/set like this:
public double CurrentTemp { get; set; }
If you need to do more complex work in the property then go ahead and define a field like this. More complex work such as conditions, calculations or raising events:
double _currentTempFarenheit;
double _currentTempCelcius;
public double CurrentTemp
{
get
{
if(UseFarenheit)
return _currentTempFarenheit;
else
return _currentTempCelcius;
}
set
{
if(UseFarenheit)
_currentTempFarenheit = value;
else
currentTempCelcius = value;
}
}
Furthermore if you only want the value of your property to be set by the constructor of your DogTemperature class then you should make the setter private. This will only allow the property to be publically read.
public double CurrentTemp { get; private set; }
Based on #Alex Gravely's answer...
If I'm understanding your necessity for a full property: you can create full properties and backing fields like this:
private double _currentTemp;
public double CurrentTemp
{
get { return _currentTemp; }
set { _currentTemp = value; }
}
Then in your constructor for DogTemperature, you just need to set the CurrentTemp to the double you passed in:
public void DogTemperature(double temp)
{
DogTemperature = temp;
}
Depending on what usage you want to get out of the CurrentTemp property - i.e. to display in a View and updating it; you may want to read into implementing INotifyPropertyChanged. Here's a link: https://msdn.microsoft.com/en-us/library/ms229614(v=vs.100).aspx
If it is just a plain old property, and not used for anything special (such as in a model, for example); then the
public double DogTemperature { get; set; }
property will suffice; setting it in the constructor as above.
Hope this helps!
Related
I am trying to make a property in my class. What would I need to do where once the property is initialized, it cannot be changed?
These are the actual instructions:
Create a class in the existing namespace, either in an existing code
file or in a new file, to represent the amount in pounds of dirt
sample. In this class (a) do not create constructors. (b) inherit the
sand class (to make use of the sand property). (c) add a property to
represent the sample name. This property may not be changed once
initialized. (d) add a property to represent and process assignments
the quantity of clay, with a minimum value of 0. (e) add methods to
return the weight of the sample, the percentage of sand in the sample
and the percentage of clay in the sample.
I am on part (c). I have tried to exclude setters. Then, I've tried to use readonly, but it cannot work because my class cannot have constructors.
public class AmountSand //parent class
{
public class AmountSand {
private double quantity;
public double Sand {
get {
return quantity;
}
set {
if (value >= 0) quantity = value;
}
}
}
public class AmountDirt: AmountSand { //part (b): inherited the parent class, AmountSand
private string name = null;
private double clay;
public string Name { //here is where the specific property starts
get {
return name;
}
set {
if (name == null)
name = value;
}
} //ends
public double Clay {
get {
return clay;
}
set {
if (value >= 0) clay = value;
}
}
Depends on from where you would like it to be initialized.
EDIT: sorry, i didn't read that your class could have ctors, but i'll keep this in for completeness. It seems kinda weird that your class can't have ctors. May I ask why?
From the ctor:
class MyClass
{
public MyClass()
{
Name = "Muhammed";
}
public MyClass(string newName)
{
Name = newName;
}
public string Name{get;}
}
If you'd like it to be initialized from outside the class, your code is not too far off. You could even remove the backing property. I'd use
if(string.IsNullOrEmpty(Name))
rather than comparing to null.
if you'd like it to be set from a method inside your class:
public string Name{get; private set;}
Strings are already immutable by nature, so you need to clarify what you're trying to accomplish.
However, if you simply don't want anything else to be able to set the value other than the class itself, then you can make the set accessor private.
I have some doubts on the auto-implemented property. Why do we first get, and then set the value?
What you've have posted is not an auto property.
Below is an example class that contains 1 auto property and a custom property similar to what you have done.
public class MyPropertyClass
{
public MyPropertyClass(bool affectLogic)
{
_affectLogic = affectLogic;
}
private readonly bool _affectLogic;
public string MyAutoProperty { get; set; }
private string _myPropertyWithLogic;
public string MyPropertyWithLogic
{
get
{
if (_affectLogic)
_myPropertyWithLogic = "Some value";
return _myPropertyWithLogic;
}
set
{
if (_affectLogic)
{
_myPropertyWithLogic = "Some value";
}
else
{
_myPropertyWithLogic = value;
}
}
}
}
The autoproperty "MyAutoProperty" provides a mechanism for simply getting and setting property values.
What you have posted in a standard property that allows you to perhaps manipulate or return the property value based upon certain conditions. In your post you are checking to see if the value posted in is null before setting.
If you do not need to access the property outside of the class then you do not need to have the get method. If you remove the get then you are creating a "WriteOnly" property which is bad practice.
Create a public method on the class that accepts the "Alert" value. If you dont need to access the property outside of the class then dont create a property at all.
public void SetMyProperty(string value)
{
_myPropertyWithLogic = value;
}
I've just gotten started learning c#, and I'm struggling a bit with the getter and setter shorthand.
As I understand it, the two methods below are equivalent. Is this correct?
//Method 1
public string name { get; set; }
//Method 2
private string name
public string getName() { return name;}
public string setName(string newName) { this.name = newName; }
Secondly, how does this work if we wanted different access modifiers on the getter/setter and the instance variable. The following code errors, telling me that the accessor must be more restrictive than the property and that I can't specify modifiers for bother accessors. Can somebody please clarify?
private int maxTime { public get; public set; }
EDIT: To clarify, I have no specific goal, only to understand. I don't understand what this shorthand notation does. In other languages I've had private instance variables and used public getters and setters to manage these instance variables. It allows this if I write out the methods on my own, but not with this shorthand notation. Why is this?
EDIT2: One last question to check my understanding. Both of the code snippets below use properties to manage the maxTime variable. The only difference between the two is style. Is this correct?
private int maxTime;
public int MaxTime{ get; set; }
vs
private int maxTime;
public int MaxTime
{
get { return maxTime; }
set { maxTime= value; }
}
Instead of the wrong private int maxTime { public get; public set; },
you can write a property that will populate a private field:
private int maxTime;
public int MaxTime
{
get { return maxTime; }
set { maxTime = value; }
}
This is useful when you want to apply logic when getting or setting the value of maxTime. if not, a simple shorthand property will do:
public int MaxTime { get; set; }
You can create a property that have a public getter but a private setter, like this:
public int MaxTime { get; private set; }
This is useful for readonly properties, and usually the property is populated in the constructor of the class.
You can even create a property where the setter is public but the getter is private, though I can't imagine any scenario this would be useful. Moreover, code standards claim that such a thing should be a method, not a property.
(read this)
public int MaxTime { private get; set; }
The answer your question in edit 2 is no.
the first code never change the private int maxTime, while the second one does. However, if inside your class you only use the property MaxTime, then they are functionally equivalent.
Update:
Since c# 6 you can write shorthand properties without a setter:
public int MaxTime {get;}
These properties can only be initialized in the constructor, or hard coded like this: (also a new feature of c# 6)
public int MaxTime {get;} = DateTime.Now;
This is useful for immutable properties (unlike readonly properties, the value of such a property can not change even inside the hosting class once initialized.
//Method 1
public string name { get; set; }
//Method 2
public string name
public string getName() { return name;}
public string setName(string newName) { this.name = newName; }
The above 2 methods are not equivalent.
It would be more accurate to compare them like this:
//Method 1
public string name { get; set; }
//Method 2
private string name; // this is private, not public.
public string Name // this is a property, not a method.
{
get
{
return this.name;
}
set
{
this.name = value;
}
}
And if you want to play with access modifiers, like make the get public, and the set private, then you would do it like this:
public int maxTime { get; private set; }
More info on Auto-Implemented Properties and the compiler magic that goes on behind the scenes.
public string name { get; set; }
What you have is Auto-Implemented property, which would internally have a backing private field (and compile time methods for get/set).
In C# code this would be equivalent to:
private string _name;
public string name
{
get { return _name; }
set { _name = value; }
}
At compile time, get/set are converted into method calls, somewhat similar to what you have.
For:
private int maxTime { public get; public set; }
The error is pretty clear, you can't have less restrictive access specifiers than the property itself. For example, if you want your public property to have a public get, but if you only want to allow setting the property from inside the class you can do:
public int maxTime { get; private set; }
You should also see: .Net Naming conventions, It would be better if you follow that, so you could have your property name starting with an upper case letter.
The first method is simply C# syntactic sugar for an automatically implemented property. It provides an implementation of the appropriate accessors when you come to compile it.
The second example is different. Here, you have a public-scope field (normally a no-no because of the principle of encapsulation) and two methods which access the variable. There's a subtle difference in semantic usage; typically properties are used to expose state, whereas a method normally indicates that the method has some computation behind it and isn't just going to return or change current state (again, this is a convention, not a hard-and-fast rule) Methods are normally styled with VerbAction naming (public Thing GetAThing() { }).
Auto-generated properties can have different access modifiers, but must only make the get or set less accessible than the overall modifier.
public int X { get; private set; } // OK
public int X { private get; set; } // OK
private int X { public get; public set; } // NOT OK
When you use a property like in Method 1 (public string name { get; set; }), the compiler automatically generates a private backing string variable and public getter and setter methods.
The general idea is to make fields private and allow access only through public getter/setter methods. So if you use Method 2 declare the variable private.
I'd recommend to use ILDASM to peruse the generated IL, it helps to see what's going on under the hood.
The second error is simply what the compiler says. The visibility of the constructs must be consistent
I am asking a beginner level question. Though I am working in MVC but I am really confused with a simple concept and that is "Properties". There are lot of questions that
I have already gone through but there is surely a doubt in mind and did'nt able to clear it up.
Actually c# properties used for getting and setting the value to the private fields.
Like
Public class MyClass
{
private int number;
public int Number{
get{ return this.number;}
set{ number=Value }
}
}
class Program
{
static void Main()
{
MyClass example = new MyClass();
example.Number = 5; // set { }
Console.WriteLine(example.Number); // get { }
}
}
Now , the value is assigned to property also and to the variable also. Right?
Now , here is my doubt::
When we create property in model for MVc structure, we only have
public int Number{get;set;}
If this is okay to work with then why we are creating unnecessorily one more field of private access specifier. If encapsulation is the reason for that or hiding the data then why not in model in MVC?
Actually, in the above class example can I only use
Console.WriteLine(example.number);
after declaring it public?
Then what's the use of creating property over here?
Properties can be used to a store and retrieve values from a backing field (number in your case) directly as in your first sample. But property getters and setters are ordinary blocks of code that you can use as you want. So you don't have to assign a backing field, but can derive the value of a property also from another property in a getter, e.g.
public int NumberTimesTwo
{
get
{
return Number * 2;
}
}
However, as a common scenario is to have a property retrieve and assign the value of a backing field, there is a shortcut that you can use:
public int Number { get; set; }
In this case, the compiler automatically creates a private backing field that the property retrieves in the getter and assigns in the setter, so the code is equivalent to the following, but less to type:
private int _number;
public into Number
{
get
{
return _number;
}
set
{
_number = value;
}
}
As the backing field is also private, you cannot access it from outside of the class directly.
private int myVar;
public int MyProperty
{
get { return myVar; }
set { myVar = value; }
}
You are implementing Encapsulation by using MyProperty, which is public to access myVar which is private and is accessible only in the block where defined, that is, your class and not outside it.
Btw, in what way does this QA not answer your question? Try going through this for further reference.
I just wonder is there is a logical reason why read-only and write-only automatic properties are not supported by c#.
(i.e. I mean properties with only a get or set, but not both. If you try to define an automatic property like this, you get a compiler error telling you that auto properties must have both get and set).
Is it just to stop people accidentally forgetting to add one?
Thanks
From the C# 3.0 spec:
When a property is specified as an
automatically implemented property, a
hidden backing field is automatically
available for the property, and the
accessors are implemented to read from
and write to that backing field.
Because the backing field is
inaccessible, it can be read and
written only through the property
accessors. This means that
automatically implemented read-only or
write-only properties do not make
sense, and are disallowed. It is
however possible to set the access
level of each accessor differently.
Thus, the effect of a read-only
property with a private backing field
can be mimicked like this:
public class ReadOnlyPoint {
public int X { get; private set; }
public int Y { get; private set; }
public ReadOnlyPoint(int x, int y) { X = x; Y = y; }
}
You can make a read-only property by making the setter private:
class A {
public int Foo { get; private set; }
}
What are you trying to get here when there never will be a set value?
MyPorperty { get; }
Even if you set the property, what is the benefit if you cannot get the value anyways?
MyProperty { set; }
If you want external code to only see set or get accessors, you can use the private keyword like this:
MyProperty { get; private set; }
or
MyProperty { private get; set; }
If you have only a getter, how could this auto-property return something usefull ?
The same logic apply for the setter.
:)
If your idea is inheritance then, you can flag it abstract and do what you want :
//this compiles successfully
public abstract Name { get; }
//this tooo
public abstract Age { set; }
Um, what would you do with such a property? There's no way to assign a value to an automatic property other than via the setter, and there's no way to read from one other than via the writer. So what use would it be to be able to read a value that can only ever be the default or to write a value that you'll never be able to get back?