Hello,
I’m learning C# , and i’m wondering what’s the difference , in terms of use, between static and data encapsulation.
What i understood is that a static variable ( or method) can be accessed from another classe without creating a instance of its class. With data encapsulation ( using get and set), i can access a private variable from another class.
So, when should i use static and when should i use data encapsulation ? Is it a matter of good practice ?
Thanks !
First of all, static and properties are neither exchangable not have anything in common, they are concepts that address two completely different problem domains.
Properties are syntactic sugar for the usual get/set methods. These will be generated by the compiler anyway but properties allow for shorter and field-like syntax, but with method-like (parameter-less) behaviour.
You can use properties for static fields as well as for non-static fields. Both kinds of fields should usually be encapsulated. Even if you do nothing else than getting and setting the values, if the ability is provided. Tutorials, especially for Unity, often break encapsulation due to Unity ability to serialize inspector values. There are various ways to achieve the same effect, one of them being the use of an [SerializedField] attribute and if needed, getter/setter for the fields with the appropriate access restriction.
An exception to that are readonly and constant fields. These are often exposed without getter and setter, as these cannot be changed (i.e. re-assigned in this case) by anyone else anyway.
Note that fields marked readonly differ from fields that you only provide a getter for, it’s not an equivalent either.
So in regards to the static keyword, this defines whether a member (a field, a method, property, event …) exists once per type, or for every instance. Static members exist from the first access of the type to the end of the application, simply said. Static can also be used in other contexts, such as making a class completely static. This prevents instantiation, inheritence etc and is useful for Utility / Helper classes.
But back to static members:
Static members are not bound to an instance and can therefore always be accessed, even without the existence of a single instance, given that the context and the access level allows it.
Visual Basic for example calls this “shared”. Maybe this helps you to understand it a little better.
This being said, let’s summarize and point out that you can have
As an example, imagine a Person class.
A person may have a name, an age and a phone number.
Each individual person should have its own name, number and phone number. These are fields that must not be static.
In contrast to that, you can, for example, implement a counter that counts the total number of created persons. If you decided to implement the counter directly into the person class, you’d have a static field that exists once for the Person type.
You can provide get-accessors for all of the fields if you want to expose their values, but restrict some of them to be not-writable, for instance the counter. Nothing else than the Person class should ever be allowed to manipulate the counter variable, as it’s purely and only managed by your own type - the Person class.
@Suddoha , thanks a lot for your answer, it’s very clear and precise !