The purpose of Access modifiers is to hide data members from unauthorized access. while the purpose of Properties is to expose Access modifiers. Where the purpose of access modifier dies. The following is the example.
public class Employee
{
private int EmployeeID;
private string Name;
private int Salary;
public int EID { get { return this.EmployeeID; } set { this.EmployeeID = value; } }
public string EName { get { return this.Name; } set { this.Name = value; } }
public int ESalary { get { return this.Salary; } set { this.Salary = value; } }
}
static void Main(string[] args)
{
Employee Employee = new Employee();
Employee.EName = "Zaheer";
}
Here i can access property EName which indirectly access Name. Any comments nd sorry if the question is silly.
The idea of a private field is not that there is no way, whatsoever, for that value to be modified by something from outside of the type. If that were true they would be entirely useless. The idea of a private field is that direct access to the member itself is prohibited from outside of the type, but a limited degree of indirect access can be allowed through some number of non-private members. Those public members will provide some more limited means of accessing the field than public access does.
In your particular example there really isn't much restriction taking place; the value can be accessed at any time by anyone with an instance, or set any time by anyone with an instance. It's still a tad more protected than exposing the field publicly, for example you can't directly create a reference to the field through a ref parameter on a method, but you're right to say that there is very little protection added. It becomes much more useful when the ability of an external entity to modify the field is limited in some way. Perhaps it can get the value and not set it, perhaps certain values can't be set at all, perhaps it will change itself in ways never specified directly by any external entity when methods are called.
The idea at the end of the day is that the definition of the methods/properties will determine what level of access there is to the underlying fields. That level of access can range from almost complete to almost nothing.
You got it a bit wrong. Properties are data members and access modifiers are the ones that modify the access to the data members. Properties are accessible from outside because they have the 'public' access modifier.
Properties are actually a syntactic sugar for methods that return and set a value of a field. Therefore, they have several advantages:
Properties can perform additional checks. Like, you can catch attempts to set EID to a negative value or EName to an empty string.
Properties can set several fields at once to keep the inner data of the object consistent.
Properties can be used in interfaces, while fields cannot.
Properties can have separate access modifiers for getters and setters.
However, setting a field is more efficient because it does not have the overhead of invoking a method.
Your example properties are all very simple and could be replaced by automatic properties. Properties are used to control the access to a field, not just to expose the field.
As an example, if you have a property called EmailAddress, you might want to check the value for a proper email address before it is assigned. You can handle that in the setter of the property and reject any invalid values. You cannot control this inside your class when you expose a field directly.
This is one of the obvious uses of a property, but there are other uses and advantages over using fields.
Related
I just realized that the C# property construct can also be used with a private access modifier:
private string Password { get; set; }
Although this is technically interesting, I can't imagine when I would use it since a private field involves even less ceremony:
private string _password;
and I can't imagine when I would ever need to be able to internally get but not set or set but not get a private field:
private string Password { get; }
or
private string Password { set; }
but perhaps there is a use case with nested / inherited classes or perhaps where a get/set might contain logic instead of just giving back the value of the property, although I would tend to keep properties strictly simple and let explicit methods do any logic, e.g. GetEncodedPassword().
Does anyone use private properties in C# for any reason or is it just one of those technically-possible-yet-rarely-used-in-actual-code constructs?
Addendum
Nice answers, reading through them I culled these uses for private properties:
when private fields need to be lazily loaded
when private fields need extra logic or are calculated values
since private fields can be difficult to debug
in order to "present a contract to yourself"
to internally convert/simplify an exposed property as part of serialization
wrapping global variables to be used inside your class
I use them if I need to cache a value and want to lazy load it.
private string _password;
private string Password
{
get
{
if (_password == null)
{
_password = CallExpensiveOperation();
}
return _password;
}
}
The primary usage of this in my code is lazy initialization, as others have mentioned.
Another reason for private properties over fields is that private properties are much, much easier to debug than private fields. I frequently want to know things like "this field is getting set unexpectedly; who is the first caller that sets this field?" and it is way easier if you can just put a breakpoint on the setter and hit go. You can put logging in there. You can put performance metrics in there. You can put in consistency checks that run in the debug build.
Basically, it comes down to : code is far more powerful than data. Any technique that lets me write the code I need is a good one. Fields don't let you write code in them, properties do.
perhaps there is a use case with nested / inherited classes or perhaps where a get/set might contain logic instead of just giving back the value of the property
I personally use this even when I don't need logic on the getter or setter of a property. Using a property, even a private one, does help future-proof your code so that you can add the logic to a getter later, if required.
If I feel that a property may eventually require extra logic, I will sometimes wrap it into a private property instead of using a field, just so I don't have to change my code later.
In a semi-related case (though different than your question), I very frequently use the private setters on public properties:
public string Password
{
get;
private set;
}
This gives you a public getter, but keeps the setter private.
One good usage for private get only properties are calculated values. Several times I've had properties which are private readonly and just do a calculation over other fields in my type. It's not worthy of a method and not interesting to other classes so private property it is.
Lazy initialization is one place where they can be neat, e.g.
private Lazy<MyType> mytype = new Lazy<MyType>(/* expensive factory function */);
private MyType MyType { get { return this.mytype.Value; } }
// In C#6, you replace the last line with: private MyType MyType => myType.Value;
Then you can write: this.MyType everywhere rather than this.mytype.Value and encapsulate the fact that it is lazily instantiated in a single place.
One thing that's a shame is that C# doesn't support scoping the backing field to the property (i.e. declaring it inside the property definition) to hide it completely and ensure that it can only ever be accessed via the property.
The only one usage that I can think of
private bool IsPasswordSet
{
get
{
return !String.IsNullOrEmpty(_password);
}
}
Properties and fields are not one to one. A property is about the interface of a class (whether talking about its public or internal interface), while a field is about the class's implementation. Properties should not be seen as a way to just expose fields, they should be seen as a way to expose the intent and purpose of the class.
Just like you use properties to present a contract to your consumers on what constitutes your class, you can also present a contract to yourself for very similar reasons. So yes, I do use private properties when it makes sense. Sometimes a private property can hide away implementation details like lazy loading, the fact that a property is really a conglomeration of several fields and aspects, or that a property needs to be virtually instantiated with each call (think DateTime.Now). There are definitely times when it makes sense to enforce this even on yourself in the backend of the class.
I use them in serialization, with things like DataContractSerializer or protobuf-net which support this usage (XmlSerializer doesn't). It is useful if you need to simplify an object as part of serialization:
public SomeComplexType SomeProp { get;set;}
[DataMember(Order=1)]
private int SomePropProxy {
get { return SomeProp.ToInt32(); }
set { SomeProp = SomeComplexType.FromInt32(value); }
}
I use private properties to reduce code for accessing sub properties which often to use.
private double MonitorResolution
{
get { return this.Computer.Accesories.Monitor.Settings.Resolution; }
}
It is useful if there are many sub properties.
One thing I do all the time is store "global" variables/cache into HttpContext.Current
private static string SomeValue{
get{
if(HttpContext.Current.Items["MyClass:SomeValue"]==null){
HttpContext.Current.Items["MyClass:SomeValue"]="";
}
return HttpContext.Current.Items["MyClass:SomeValue"];
}
set{
HttpContext.Current.Items["MyClass:SomeValue"]=value;
}
}
I use them every now and then. They can make it easier to debug things when you can easily put in a breakpoint in the property or you can add a logging statement etc.
Can be also be useful if you later need to change the type of your data in some way or if you need to use reflection.
I know this question is very old but the information below was not in any of the current answers.
I can't imagine when I would ever need to be able to internally get but not set
If you are injecting your dependencies you may well want to have a Getter on a Property and not a setter as this would denote a readonly Property. In other words the Property can only be set in the constructor and cannot be changed by any other code within the class.
Also Visual Studio Professional will give information about a Property and not a field making it easier to see what your field is being used.
It is a common practice to only modify members with get/set methods, even private ones. Now, the logic behind this is so you know your get/set always behave in a particular way (for instance, firing off events) which doesn't seem to make sense since those won't be included in the property scheme... but old habits die hard.
It makes perfect sense when there is logic associated with the property set or get (think lazy initialization) and the property is used in a few places in the class.
If it's just a straight backing field? Nothing comes to mind as a good reason.
Well, as no one mentioned you can use it to validate data or to lock variables.
Validation
string _password;
string Password
{
get { return _password; }
set
{
// Validation logic.
if (value.Length < 8)
{
throw new Exception("Password too short!");
}
_password = value;
}
}
Locking
object _lock = new object();
object _lockedReference;
object LockedReference
{
get
{
lock (_lock)
{
return _lockedReference;
}
}
set
{
lock (_lock)
{
_lockedReference = value;
}
}
}
Note: When locking a reference you do not lock access to members of the referenced object.
Lazy reference: When lazy loading you may end up needing to do it async for which nowadays there is AsyncLazy. If you are on older versions than of the Visual Studio SDK 2015 or not using it you can also use AsyncEx's AsyncLazy.
One more usage would be to do some extra operations when setting value.
It happens in WPF in my case, when I display some info based on private object (which doesn't implement INotifyPropertyChanged):
private MyAggregateClass _mac;
private MyAggregateClass Mac
{
get => _mac;
set
{
if(value == _mac) return;
_mac = value;
PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(nameof(DisplayInfo)));
}
}
public string DisplayInfo => _mac.SomeStringInformationToDisplayOnUI;
One could also have some private method, such as
private void SetMac(MyAggregateClass newValue)
to do that.
Some more exotic uses of explicit fields include:
you need to use ref or out with the value - perhaps because it is an Interlocked counter
it is intended to represent fundamental layout for example on a struct with explicit layout (perhaps to map to a C++ dump, or unsafe code)
historically the type has been used with BinaryFormatter with automatic field handling (changing to auto-props changes the names and thus breaks the serializer)
Various answers have mentioned using properties to implement a lazy member. And this answer discussed using properties to make live aliases. I just wanted to point out that those two concepts sometimes go together.
When using a property to make an alias of another object's public property, the laziness of that property is preserved:
[DebuggerBrowsable(DebuggerBrowsableState.Never)]
private IDbConnection Conn => foo.bar.LazyDbConnection;
On the other hand, retrieving that property in the constructor would negate the lazy aspect:
Conn = foo.bar.LazyDbConnection;
Looking into the guideline (Properties (C# Programming Guide)) it seems no one expects to use properties as private members.
Properties enable a class to expose a public way of getting and setting values, while hiding implementation or verification code.
In any case it can be interchanged by one or two methods and vice versa.
So the reason can be to spare parentheses on getting and get field syntax on setting.
I have seen some code and thought that something seems wrong with it, so I would like to know if it is acceptable for good coding or not, my first thought is no.
Consider:
class MyClass
{
private string m_MySuperString;
public string MySuperString
{
get { return m_MySuperString; }
set { m_MySuperString = value; }
}
public void MyMethod()
{
if (blah != yada)
{
m_MySuperString = badabing;
}
}
public void MyOtherMethod()
{
if (blah == yada)
{
m_MySuperString = badaboom;
}
}
}
Is this kind of direct access to the Backing Field an acceptable practice or is it bad coding - or should I ask what is the point of the Property Accessor, and if this is done internally in a class with public members , access is allowed by multiple components - is it possible to have a crash - I would venture in a multi threaded application a crash should be expected.
Please any thoughts ?
I have looked at this Link on SO and others>
Why use private members then use public properties to set them?
EDIT
Let me be clear since there is good info being provided and rather respond to all answers and comments directly.
I am not asking about what properties are for, not if I can do auto implemented properties, private setters, OnValueChange notifications, logic on the properties.
My question is in regards to accessing that backing field directly - for example if you have say a mutlithreaded scenario - isn't the whole point of the synclock on the getters/setters - to control access to the backingfield ? Will this kind of code be acceptable in that scenario - just adding a syncLock to the getter and setter ?? Keep in mind the code in the constructor of myClass is an example - the code can be in any additional method - such as the updated class - Method1
END EDIT
Properties in Object Oriented Programming (OOP) help to enforce Encapsulation. The idea is that only the object itself is allowed to interact with its own data (i.e. fields). Access to the object's data from outside is only allowed through methods. In Java, for instance, you have to explicitly write get- and set-methods. Properties in C# have a special syntax that combines both of these methods in one construct, but the getters and setters are in fact methods.
This also means that an object is absolutely allowed to access its own fields directly.
There are cases, however, where property getters and setters perform additional logic. A setter might raise the PropertyChanged event or do some validation. A getter might combine several fields or yield a formatted or calculated value. If you need this additional logic to be performed, then you must access the properties instead of the fields. If a property is auto-implemented, then you have no choice (in C#), since the backing field is hidden and not accessible. (In VB it is hidden from IntelliSense but accessible from within the class.)
I recommend checking out Chapter 8, Section 1 of #JonSkeet's C# In Depth (from which I've shamelessly taken the below snippets for the purpose of education) for more information on automatically implemented properties. In short answer to your question, no, there's nothing wrong with this code.
Consider that the following snippet:
public string Name { get; set; }
is compiled as
private string <Name>k__BackingField;
public string Name
{
get { return <Name>k__BackingField; }
set { <Name>k__BackingField = value; }
}
...so the compiler is already doing the work for you that you've done above. There are ways to modify what it's doing, but those don't really answer the question. One example given in the book for thread safety is this:
//code above, plus
private static int InstanceCounter { get; set; }
private static readonly object counterLock = new object();
public InstanceCountingPerson(string name, int age) {
Name = name;
Age = age;
lock (counterLock) // safe property access
{
InstanceCounter++;
// and whatever else you have to do with the lock enabled
}
}
--Which is a pattern also referenced in this SO question. However, as pointed out there, locks are (a) potentially slow, (b) might not actually ensure their job is done because they have to be released at some point, and (c) rely on the trust system, because they sort of naively assume that anything wanting to access that object will make proper use of the lock (not always true, at least not in some of the code I've seen :D ). The advantage of the getter and setter methods is that you can enforce the pattern of using the lock (read: properly encapsulate the field, as others have suggested) for any instance of your class.
Another pattern you might consider, however, is Inversion of Control. With a Dependency Injection container, you can specify the level of thread safety you are comfortable with. If you are comfortable with everyone waiting for a singleton instance of your object, you can declare that all references to the object's interface reference the same object (and must wait for the object to become available), or you can determine that a thread-safe instance of the object should be created each time it is requested. See this SO answer for more details.
Note:
Any peer-reviewed criticism of the above ideas will be graciously accepted and added to the answer, as I'm sort of a thread safety dilettante at this point.
In the use case described , You can define this as follows using auto-implemented properties
public string MySuperString{ get; set ;}
you should use a backing filed if you need to do some input verification or the property is different than the internal fields for example
public string FullName{ get { return firstName + LastName} }
another benefit of using properties is you can define them in an interface , which is better in the long run for future features to be added
This question already has answers here:
Auto-implemented getters and setters vs. public fields
(17 answers)
Closed 8 years ago.
I have looked at at least 10 SO questions on get/set but cannot find mine. So I hope this is not a duplicate.
public class myint
{
public int value{get;set;}
}
vs
public class myint
{
public int value;
}
The above 2 codes look the same to me. If I want to use the myint class, I just write the code below and it can run on either class.
myint A;
A.value=10;
So what is the get/set use for?
You're asking what the difference is between using a public instance variable vs. getter/setter properties I assume.
Properties allow you to further encapsulate logic around getting or setting a variable, for example adding simple validation logic. You could throw an exception if someone sets your value to less than zero for example. You could also add further logic in the getter/setter to for example synchronize a specific field.
A few other differences:
Properties can be used for data binding easily in most .NET UI frameworks.
Reflection works differently.
Differing access levels for get/set vs. for example your instance variable you can choose between readonly, private, protected, static, etc. as a whole.
There is more overhead accessing a property. This is usually unimportant in most use cases other than games and highly performance sensitive situations.
http://msdn.microsoft.com/en-us/library/x9fsa0sw.aspx
A property is a member that provides a flexible mechanism to read,
write, or compute the value of a private field. Properties can be used
as if they are public data members, but they are actually special
methods called accessors. This enables data to be accessed easily and
still helps promote the safety and flexibility of methods.
Here are few things off the top of my head that differentiate a public {get;set;} vs a public member variable:
Properties are needed for data binding.
get and set can have different accessors (e.g. public int Value {get; protected set;}
get;set; can be part of a interface e.g. interface IHasValueGetter { public int Value {get;}}
What is the difference between a Field and a Property in C#?
here is when do we use get set
According to the Property Usage Guidelines on MSDN:
Use a property when the member is a logical data member. In the following member declarations, Name is a property because it is a
logical member of the class.
Use a method when:
The operation is a conversion, such as Object.ToString.
The operation is expensive enough that you want to communicate to the user that they should consider caching the result.
Obtaining a property value using the get accessor would have an observable side effect.
Calling the member twice in succession produces different results.
The order of execution is important. Note that a type's properties should be able to be set and retrieved in any order.
The member is static but returns a value that can be changed.
The member returns an array. Properties that return arrays can be very misleading. Usually it is necessary to return a copy of the
internal array so that the user cannot change internal state. This,
coupled with the fact that a user can easily assume it is an indexed
property, leads to inefficient code. In the following code example,
each call to the Methods property creates a copy of the array. As a
result, 2n+1 copies of the array will be created in the following
loop.
you can remove get and set it will not affect the code and working due to the reason that you have defined a variable of type int with the Access type of public so that properties are mostly used to access the private members of class which is in your case do not exist so go on and remove it how ever if in top most class you define a variable with Private modifier the to access it get and set are necessary properties!
// This is an example of property...
public class myint
{
public int value{get;set;}
}
// This is an example of field...
public class myint
{
public int value;
}
The difference:
Databinding techniques only works on properties, and not on fields
Fields may be used as input to out/ref arguments. Properties may not.
Properties may throw exceptions - fields will never do that
Example:
class Person
{
private string _name;
public string FirstName
{
get
{
return _name ?? string.Empty;
}
set
{
if (value == null)
throw new System.ArgumentNullException("value");
_name = value;
}
}
}
Properties support different accessibility for getters/setters - fields do not (but fields can be made readonly)
I have a confusion about understanding Property and Variables
public class ABC()
{
public int A;
public int B { get; set; }
}
What is the exact difference between in A and B?
As many have pointed out, A is a field, B is a property.
The real question is, why should you care, and what to use?
I refer to a blog post of Jonathan Aneja:
(Its in VB, but it applies to C# as well ;))
So why use properties over fields, 5 reasons:
1. Fields can’t be used in Interfaces
You can’t enforce the existence of a
field in an object’s public contract
through an interface. For properties
though it works fine.
2. Validation
While your application currently may
not require any validation logic to
set a particular value, changing
business requirements may require
inserting this logic later. At that
point changing a field to a property
is a breaking change for consumers of
your API. (For example if someone was
inspecting your class via reflection).
3. Binary Serialization
Changing a field to a property is a
breaking change if you’re using binary
serialization. Incidentally, this is
one of the reasons VB10’s
auto-implemented properties have a
“bindable” backing field (i.e. you can
express the name of the backing field
in code) – that way, if you change an
auto-implemented property to an
expanded property, you can still
maintain serialization compatibility
by keeping the backing field name the
same (in C# you’re forced to change it
because it generates backing fields
with unbindable names).
4. A lot of the .NET databinding infrastructure binds to properties but not fields
I’ve heard arguments on both sides as
to whether or not that’s a good thing,
but the reality is that’s the way it
works right now. (Note from me: WPF bindings work on properties)
5. Exposing a public field is an FxCop violation
For many of the reasons listed above
:)
There might be more reasons.
I would also like to point to a blog post of Jeff Atwood and conclude with a quote from it:
The really important thing to take away here is to avoid writing code that doesn't matter. And property wrappers around public variables are the very essence of meaningless code.
A is a field, B is a property. A property is basically syntactic sugar for getters and setters. The class you have defined will be compiled into something like this:
public class ABC()
{
public int A;
private int backing_B;
public void set_B(int value)
{
backing_B = value;
}
public int get_B()
{
return backing_B;
}
}
Note that this kind of conversion is true for all C# properties -- accesses to ABC.B will be converted to method calls. Properties basically provide the illusion of a "variable" while actually just being a cleverly disguised pair of methods.
This is important, because it allows you to declare your own get and set method body, which can validate values or do other interesting things:
private int b;
public int B {
get { return b; }
set {
if (value < 0) throw new ArgumentOutOfRangeException("value");
b = value;
}
}
Note that most properties will use a field to store their value. Properties seldom exist on their own, apart from fields.
In C# any "variable" that has a getter and setter is referred to as a property. A variable has no getters and setters or so that is what the text books say.
My programming instructor made us have getters and setters for almost every variable that we created in Java. Even indexing variables he made us use a getter and setter if they were declared at the global class scope. I think this might have been overkill but it did get me to make getters and setters.
The real things about getters and setters are that they more than likely do more than just set an internal variable. Most setters are going to perform some type of data validation to make certain that data can be set to the variable. A getter might also check returning data for some criteria.
If your property is private and your setters and getters are public technically anyone could access your variable and change it as if they had public access to the actual variable. So, in reality, you should check your data to make certain that it is valid or some other data check.
private int myVariable;
public int myVariable
{
get
{
return myVariable;
}
set
{
if (value < 0)
{
throw new Exception("This is your exception some where else in code");
}
myVariable = value; //remember value is something that is
//declared automatically
}
}
public string FirstName { get; set; }
The above is a shorthand way of writing the following
private string firstName;
public string FirstName
{
get
{
//...code here
}
set
{
//...code here
}
}
A property is sort of a short getter and or setter. You can add logic to the set or get of the property or make them private which means that they are not accessible from the out side, where a variable is always accessible (if it is public).
Variable is, well, a variable.
Property is a special type of method that exposes that variable. And since it is a method, therefore, you can do some other things in it apart from just exposing the variable.
From MSDN:
The Property statement introduces the declaration of a property. A property can have a Get procedure (read only), a Set procedure (write only), or both (read-write). You can omit the Get and Set procedure when using an auto-implemented property. For more information, see Auto-Implemented Properties (Visual Basic).
You can use Property only at class level. This means the declaration context for a property must be a class, structure, module, or interface, and cannot be a source file, namespace, procedure, or block. For more information, see Declaration Contexts and Default Access Levels.
By default, properties use public access. You can adjust a property's access level with an access modifier on the Property statement, and you can optionally adjust one of its property procedures to a more restrictive access level.
There is a very good article (link below) about using fields/variables vs Properties from Microsoft itself. Though the article essentially talks about a FxCop violation rule, it clearly defines the difference between the two and the exact usage guidelines.
An excerpt from the article:
The primary use of a field should be as an implementation detail.
Fields should be private or internal and should be exposed by using
properties. Accessing a property is as easy as accessing a field, and
the code in a property's accessors can change as the type's features
expand without introducing breaking changes.
Refer:
https://learn.microsoft.com/en-us/previous-versions/dotnet/netframework-3.0/ms182141(v=vs.80)
In your example A is a public field on the class ABC and B is a public property on the class ABC. Specifically, B is an auto-implemented property. What this means is that "under the hood" the compiler does some of the work for you and effectively transforms your code into:
public class ABC()
{
private int b;
public int A;
public int B
{
get
{
return b;
}
set
{
b = value;
}
}
}
Variable is defined basically for accessing value from a class or into the same class according to their modifier assigned to those variable.
When we define a property there two methods created for single property so extra overhead is generated that is the drawback of property.
The advantages of properties is to get or set value into private variable of class.
I see a lot of example code for C# classes that does this:
public class Point {
public int x { get; set; }
public int y { get; set; }
}
Or, in older code, the same with an explicit private backing value and without the new auto-implemented properties:
public class Point {
private int _x;
private int _y;
public int x {
get { return _x; }
set { _x = value; }
}
public int y {
get { return _y; }
set { _y = value; }
}
}
My question is why. Is there any functional difference between doing the above and just making these members public fields, like below?
public class Point {
public int x;
public int y;
}
To be clear, I understand the value of getters and setters when you need to do some translation of the underlying data. But in cases where you're just passing the values through, it seems needlessly verbose.
I tend to agree (that it seems needlessly verbose), although this has been an issue our team hasn't yet resolved and so our coding standards still insist on verbose properties for all classes.
Jeff Atwood dealt with this a few years ago. The most important point he retrospectively noted is that changing from a field to a property is a breaking change in your code; anything that consumes it must be recompiled to work with the new class interface, so if anything outside of your control is consuming your class you might have problems.
It's also much simpler to change it to this later:
public int x { get; private set; }
It encapsulates setting and accessing of those members. If some time from now a developer for the code needs to change logic when a member is accessed or set it can be done without changing the contract of the class.
The idea is that even if the underlying data structure needs to change, the public interface to the class won't have to be changed.
C# can treat properties and variables differently at times. For example, you can't pass properties as ref or out parameters. So if you need to change the data structure for some reason and you were using public variables and now you need to use properties, your interface will have to change and now code that accesses property x may not longer compile like it did when it was variable x:
Point pt = new Point();
if(Int32.TryParse(userInput, out pt.x))
{
Console.WriteLine("x = {0}", pt.x);
Console.WriteLine("x must be a public variable! Otherwise, this won't compile.");
}
Using properties from the start avoids this, and you can feel free to tweak the underlying implementation as much as you need to without breaking client code.
Setter and Getter enables you to add additional abstraction layer and in pure OOP you should always access the objects via the interface they are providing to the outside world ...
Consider this code, which will save you in asp.net and which it would not be possible without the level of abstraction provided by the setters and getters:
class SomeControl
{
private string _SomeProperty ;
public string SomeProperty
{
if ( _SomeProperty == null )
return (string)Session [ "SomeProperty" ] ;
else
return _SomeProperty ;
}
}
Since auto implemented getters takes the same name for the property and the actual private storage variables. How can you change it in the future? I think the point being said is that use the auto implemented instead of field so that you can change it in the future if in case you need to add logic to getter and setter.
For example:
public string x { get; set; }
and for example you already use the x a lot of times and you do not want to break your code.
How do you change the auto getter setter... for example for setter you only allow setting a valid telephone number format... how do you change the code so that only the class is to be change?
My idea is add a new private variable and add the same x getter and setter.
private string _x;
public string x {
get {return _x};
set {
if (Datetime.TryParse(value)) {
_x = value;
}
};
}
Is this what you mean by making it flexible?
Also to be considered is the effect of the change to public members when it comes to binding and serialization. Both of these often rely on public properties to retrieve and set values.
Also, you can put breakpoints on getters and setters, but you can't on fields.
AFAIK the generated CIL interface is different. If you change a public member to a property you are changing it's public interface and need to rebuild every file that uses that class. This is not necessary if you only change the implementation of the getters and setters.
Maybe just making fields public you could leads you to a more Anemic Domain Model.
Kind Regards
It is also worth noting that you can't make Auto Properties Readonly and you cannot initialise them inline. Both of these are things I would like to see in a future release of .NET, but I believe you can do neither in .NET 4.0.
The only times I use a backing field with properties these days is when my class implements INotifyPropertyChanged and I need to fire the OnPropertyChanged event when a property is changed.
Also in these situations I set the backing fields directly when values are passed in from a constructor (no need to try and fire the OnPropertyChangedEvent (which would be NULL at this time anyway), anywhere else I use the property itself.
You never know if you might not need some translation of the data later. You are prepared for that if you hide away your members. Users of your class wont notice if you add the translation since the interface remains the same.
The biggest difrence is that, if ever you change your internal structure, you can still maintain the getters and setters as is, changing their internal logic without hurting the users of your API.
If you have to change how you get x and y in this case, you could just add the properties later. This is what I find most confusing. If you use public member variables, you can easily change that to a property later on, and use private variables called _x and _y if you need to store the value internally.
why we dont just use public fields instead of using properties then
call accessors ( get,set ) when we dont need to make validations ?
A property is a member that provides a flexible mechanism to read only or write only
Properties can be overridden but fields can't be.
Adding getter and setter makes the variable a property as in working in Wpf/C#.
If it's just a public member variable, it's not accessible from XAML because it's not a property (even though its public member variable).
If it has setter and getter, then its accessible from XAML because now its a property.
Setters and getters are bad in principle (they are a bad OO smell--I'll stop short of saying they are an anti-pattern because they really are necessary sometimes).
No, there is technically no difference and when I really want to share access to an object these days, I occasionally make it public final instead of adding a getter.
The way setters and getters were "Sold" is that you might need to know that someone is getting a value or changing one--which only makes sense with primitives.
Property bag objects like DAOs, DTOs and display objects are excluded from this rule because these aren't objects in a real "OO Design" meaning of the word Object. (You don't think of "Passing Messages" to a DTO or bean--those are simply a pile of attribute/value pairs by design).