C# Properties in Unity! – Intermediate Scripting Tutorial


– It’s common to need a way to access the member variables of a class from code that exists
outside of the class. One way you could do this would be to make the variables public and just access them directly. This is sufficient, but
there is a better way. That better way is using properties. Properties themselves act like variables and encapsulate member variables which we can also call fields. This encapsulation gives us
a greater amount of control over when and how a field is accessed. Let’s say we have a field named experience that exists in the class player and we want a way for code
existing outside of the class to access it. We would want to create a property. The syntax for a property works like this. First, you specify the access modifier. Then, you specify the type followed by the name of the property. A good rule is to name the property the same thing as the field, except starting with a capital letter. After the name of the property, you place open and closed braces, just like you would for a function. Inside these braces go
the property’s accessers. A property can have two accessers. Get and set. These are the functions that are called when a property is referenced and allocated to, respectively. They’re declared using
the key words get and set, followed by braces. Within the get accesser, we return the field that
we’re encapsulating. In the set accesser, we allocate to the field, using the keyword value. That’s all that’s required
to implement a property. Now, in another script, we can use the property
in place of the field exactly as we would do normally. You might be wondering why you
would go through the process of creating a property when you could have just used
the public access modifier for the variable to begin with. There are two things that
you can do with properties that you cannot do with public variables. The first is that by omitting
either the get or the set you can effectively make the
field write only or read only. If the field is private, you cannot read it without a get accesser and you cannot write to
it without a set accesser. The second is that accessers
can also be treated just like functions. That means that you could
run other lines of code or put calls to other
functions inside them. An extension of this idea is to start co-routines
using the set accesser. The field encapsulation
need not be direct. Consider a game where the
player gains experience and levels up after every one
thousand experience points. If you had a field to represent
the experience points, you could have a property to represent the level of the player. Instead of returning the
number of experience points, the level property’s get accesser could return the experience
field, divided by one thousand. Thus, it would return the numerical level and not the amount of
experience the player has. Furthermore, the level property
could have a set accesser that receives a level and calculates the amount of experience
the player would have and stores that in the experience field. Another feature of properties is that they can be auto-implemented. To create an auto-implemented property, you would use a shorthand syntax. In this syntax, the get and
set accessers are followed only by a semicolon. Creating a property in this way makes it behave exactly like a field, the difference being that you could make a
property read or write only by removing either the
get or set accesser. Using visual studio, it’s possible to quickly create
properties using snippets. If you type prop and
then press the tab key you can insert them automatically.

Leave a Reply

Your email address will not be published. Required fields are marked *