2

In a class we declare class members as private but we define properties as public.

For example:

public class student
{
    private int StudentId;
    private string StudentName;
    private string Address;
}

and after this we assign using method.

But if we use properties for get set define public like.

public class student
{
    public int StudentId {get;set;};
    public string StudentName{get;set;};
    public string Address{get;set;};
}

What is the reason behind this?

TheLethalCoder
  • 6,668
  • 6
  • 34
  • 69
Lalji Dhameliya
  • 1,729
  • 1
  • 17
  • 26
  • 2
    You don't do this *because* they're "class members" or "properties" (by the way, properties are members too, it's more typical to group them into static members and instance members). You usually want to encapsulate the actual implementation, so fields, which have no bound logic that happens when you access them are usually private, whereas properties where you can both control write access (who gets to write) and bound logic (what happens when you write) are more often public. You want to control the public surface of your type, and hide the actual implementation. – Lasse V. Karlsen Nov 18 '16 at 12:00
  • Nothing enforces you to use a field as private or a property as public, but usually variables are private as are meant for internal use of the class and properties are used for external use as they can execute code when they're get/set. – Gusman Nov 18 '16 at 12:01
  • 2
    this solution may clear your situation: http://stackoverflow.com/questions/295104/what-is-the-difference-between-a-field-and-a-property-in-c http://softwareengineering.stackexchange.com/questions/133015/private-variable-vs-property – SURJEET SINGH Bisht Nov 18 '16 at 12:02
  • See https://blogs.msdn.microsoft.com/vbteam/2009/09/04/properties-vs-fields-why-does-it-matter-jonathan-aneja/ – Ian Mercer Nov 18 '16 at 12:05

6 Answers6

3

That's not quite it. The real rule is:

Define all members as restrictively as they can to be.

So, if it can be private then it's private. Otherwise if it has to be internal or protected to work, then it's internal or protected respectively. Otherwise if it has to be protected internal to work, then it's protected internal. Otherwise it's public because it has to be public to work (something outside of the assembly that doesn't inherit from it is going to have to access it.

Now, all that said, it is generally true that we'll have mostly private fields and mostly public properties.

Let's consider if we do have a public field. That's valid, will work, and is even useful in very limited cases. However it's also more brittle. Having it public lets any other code set it to any value, no matter how stupid. That's okay because when we make a field public we're saying "there are no stupid values".*

But what if we suddenly realise there are some stupid values, or we need to do something every time the field is changed, or we need to work with some property-only data-binding. Here we're going to have to turn the field into a property, and that's a breaking change; any code using this class will have to be re-compiled, which isn't that big a deal if we're the only person using the class, but is if it's in a library being used by others.

If it had been a property however, then we'd just have had to turn an auto-property { get; set; } into a property with custom implementation { get { /* do stuff and return value */ } set { /* do stuff */ } }. From outside the class it looks like nothing has changed and we haven't broken anything.

Therefore 99.99% of the time if you are going to make a field public you're better of using a property there, just in case.

On the other hand, if we've a private property that has no logic, then the getter and setter methods do not give us any benefit. There won't be any cost, but they're pointless. So we just use a field instead. If we end up having to use a private property in the future that won't matter because the only code that has to be recompiled is the very class in question, and we were re-compiling it anyway.

As such we end up with the case where almost all fields are private and almost all properties that don't have any custom logic are protected or public.

*Or it's a private or internal class and we promise from the outside not to set it to something stupid, but it's better to enforce promises than to make them if you can.

Jon Hanna
  • 110,372
  • 10
  • 146
  • 251
2

A class needs to control the behavior of its public members: i.e. to control what they do

Imagine for example if private string StudentName; was made public and so used by external code (outside class student). Then you decide you want to add a validation to limit the length of StudentName - how can you do that? You will have to find all the instances in your code (and possibly other people's code using this class) that sets the value of StudentName and add validation there.

Not if you were using public string Student {get; set;} - you can easily change it to be an explicit property with validation:

private string _student;
public string Student
{
    get { return _student; }
    set { if(value.Length <= 20) _student = value;
}

i.e. Using properties makes it easier to control the behavior of the class' members from within the class, maintaining encapsulation and abstraction

KMoussa
  • 1,568
  • 7
  • 11
0

You are right - properties are usually used as public ones. Though: You can define a property like this aswell: 

public int StudentId {get; private set;}

This will make other classes get the value of your property but they won't be able to change it.

Imagine if you would develop a project like an assembly with many complex controls in it. If you want the user to be able to read, what value is in the control, because it gets calculated you give it a public getter but a private setter, because you don't want somebody to manipulate what is Happening inside.

TripleEEE
  • 499
  • 3
  • 11
0

To not set fields directly, but through properties follows the object oriented principle of Encapsulation. That includes that a class is the boss of the data its objects contain. A class should always remain in control of accesses to its data (be they read or write). Sometimes it means that they need to do additional steps to ensure data consistency. But even if they don't, the fact that the don't should remain hidden to the callers because it's none of their business (separation of concerns). Therefore the simple rule: there are no shortcuts to object data. If you want to get some of it, you have to ask the class to give it to you. In C#, that's what a property is for.

Sefe
  • 13,731
  • 5
  • 42
  • 55
0

There are multiple reasons behind using properties and making them public

  1. Marking the class field public & exposing is a risky, as you will not have control what gets assigned & returned.

  2. Want to break into the debugger whenever the value changes? Just add a breakpoint in the setter.

  3. Want to log all access? Just add logging to the getter. Properties are used for data binding; fields aren't.

  4. Add validations on private members(like value cannot be set negative).

  5. Return some default values in case of null, empty or zero.

  6. Properties can be declared as Read/write, read-only, or write-only.

  7. Other benefits, Reflection and DataBinding.

Vivek Nuna
  • 25,472
  • 25
  • 109
  • 197
0

There is no special reason in this simplest case. But if you go further in development - it will become absolutely clear: you'll need to abstract from implementation and separate out an interface, e.g. just to mock Student in a unit test. So, in long terms you'll rather need interfaces and properties and it is just a habit to write it in a mockable and testable manner from the very beginning

public interface IStudent
{
    int StudentId { get; set; }
    string StudentName { get; set; }
    string Address { get; set; }
}

public class Student : IStudent
{
    public int StudentId { get; set; }
    public string StudentName { get; set; }
    public string Address { get; set; }
}
mikka
  • 146
  • 5