Why encapsulate this field?

Question

I was always told to encapsulate ANY and ALL properties from the class ...

It is right:

private string propertyName; public string PropertyName { get { return propertyName; } set { propertyName = value; } } 

And it is WRONG

 Public string PropertyName; 

I don’t see where encapsulation is needed ... for me, the first code is just useless redundant code ... there is no need to encapsulate this field ...

So, if someone can justify the encapsulation on THIS SCENARIO. (I can understand from other scenarios).

Answer 1

For the most part, in practice, the public field will be good. After all, if you later need to make it read-only from the outside or add behavior to its setter, you can simply change it to a property. So you can make this a public field today and change it later if you need to. Right?

The fact is, there are some cases where you cannot safely change it later:

• If you compile Foo.dll with a public field, and someone creates Bar.dll that refers to Foo.dll, you will not be able to add a new version of Foo.dll later with this field changed to a property. You would need this other person to rebuild Bar.dll against your new Foo.dll. For some stores, this is not a problem; for others, this can be a huge problem.
• If you write some kind of reflection code, the reflection from the fields is very different from the reflection of the properties. Therefore, if you later change your field to a property, your Reflection code will break.

How important are both of these scenarios? Probably not very. But it's easier to write proactively

 public string PropertyName { get; set; } 

than clearing up the mess if you need to change it later.

And there is no cost of execution. In any case, the JIT compiler will inline the getter and setter. So it costs nothing and brings some benefit; at this point why not use the property?

Answer 2

Your main complaint is the verbosity of the first implementation. Your syntax reads like C # for me, so the public String PropertyName{get;set;} would be a less verbose but equivalent statement. The usefulness is that you can change the support for the implementation of the property without changing the usages. The coding style for fields and properties usually changes, so it can at least lead to refactoring the interface, which can be painful if it is exposed to another.

Yes, in most cases this is too much.

Update: Based on the comments below, I will add a little about the differences that the compiler notes between fields and properties. You cannot use the property as an argument to ref or out, and as Robert Levy points out below, while the code reads the same thing, there is a function call allocated by the compiler, so you need to recompile dependent assemblies. You can put a property in an interface, but not in a field. So there are some pros and cons.

Answer 3

Because you can change, for example, set later to perform a check. This is not possible when using the public string PropertyName so that you are permanently stuck in a public attribute.

---

As others said in the answers, you can remove some of the cracks using this syntax:

 public string PropertyName { get; set; } 

Answer 4

It looks redundant, but it is intended to give you future flexibility without breaking the other classes that use your class.

If you start with a public string PropertyName; but later switch to defining a real property, other classes using your will must be recompiled (even if their real code does not change).

In newer versions of C # there is an abbreviation for this: public string MyProperty {get; set; } public string MyProperty {get; set; } public string MyProperty {get; set; } , which behind the scenes creates a private member that you are not using (currently).

Answer 5

You encapsulate to ensure data integrity. For example, if you have an age attribute for a person in the class, you do not want someone to store a large number, such as 19348, in this variable. If you use encapsulation, you can check this number and perform error handling when the user tries to do something like this. And by "user" I mean another programmer using your class.

Answer 6

One more example. You can easily override a property in the process of inheritance.

 class Base { public virtual string PropertyName { get; set; } } class Derived : Base { public override string PropertyName { get { return base.PropertyName + " Something"; } set { base.PropertyName = value; } } } 

Answer 7

Encapsulation allows you to change the implementation details without changing the interface to the class (this means that the code that uses the class needs to be changed). For example, later you can add some kind of check or other logic that internally changes the situation as a side effect of changing this property or even replaces the underlying storage for this property), without having to change anything using this class.

It’s a good habit to always encapsulate data, even if you don’t see the need now (and especially because most modern IDEs will automatically generate getters and setters for you).

Answer 8

I think the general idea of ​​encapsulating access methods is to make the code more flexible in the future (i.e. good programming practice).

If you need to change implementation details, shutdown notifications when certain properties are changed, track how many times access to the resource will be available, it will allow you to change encapsulation methods without affecting other code.

If you write code that is likely to be improved in the future, it deserves additional work, even at the cost of additional wording of the boiler plate.