In the previous lesson, Static class members in C# .NET, we learned about static class members in
C# .NET. In today's tutorial, we're going to look at the other class members
that we haven't gone over yet.

Properties

We often want to have control over how an object field changes from outside
of the class. We could set the field as read-only or react to its changes
somehow. Let's create a new project (name it Properties) and add the following
Student class which will represent a student in a database.

The class is very simple, the student has a name, gender, and age. The
fullAged field is set according to the age and provides a more
comfortable determination whether the student is of age from different places in
the system. We'll use a bool value to store gender, true indicates that he's
male. The constructor will determine whether the student is of age or not. The
ToString() method has been altered to suit our needs. In a real world situation,
it would probably just return the student's name. Let's create a student using
the constructor:

Console application
I am Peter Brown, female. I am 15 years old and I am of age.

Certainly, we would want fullAged to be updated when the age is
changed. Aside from that, no other field would need to be altered externally.
Students don't usually change their genders or names. However, we'll keep them
accessible for reading. In earlier parts of our course, we've used get methods
to read private fields. We would name them something like GetAge() and so on.
We'll create get methods to be able to read certain fields and make these fields
private to prevent them from being modified from the outside. The class would
now look something like this (I omitted the constructor and ToString()):

Methods used for returning values are very simple. When a user changes
his/her age, our program recalculates the fullAged field. We made sure we can't
set variables in any other way than what we want. We now control all the field
changes and can work with them as needed. Our design must prevent all
alterations of the internal state that would cause an object to malfunction.

Methods for returning values are called getters and methods
for setting values are called setters. We could potentially add
an EditStudent() method to edit other fields sort of like we did to the
constructor. Essentially, a student's name, age, and other fields would be
updated using this method. We could also validate values being set there since
we would be able to handle all attempts to change certain values in one place.
Implementing getters and setters manually is without a doubt hard work. Couldn't
someone just do it for us? Yep, C# is able to generate them for us! In that
case, we're no longer talking about fields, rather
properties.

The property syntax is very similar to the field syntax:

publicstring Name { get; set; }

At first, it may seem as if we had declared a field. The property name is
capitalized because it is actually a method (2 methods to be precise). In curly
brackets, we would specify the methods we wish to generate. We don't write a
semicolon after properties! In the example above, both the setter and the getter
would be generated, and the property would be accessible both for reading and
writing:

From the outside, the only significant difference against an attribute is
that the first letter is uppercase. C# internally generates a private field and
two public methods that are called automatically depending on the context
(whether we read or write the value). If we didn't generate the setter part of
the property, there would be no way to change the property from the inside nor
the outside. If you want to prevent all alteration of your variable from outside
the class, you would just make its setter private:

publicstring Name { get; privateset; }

We'll use this very often and most of the properties in our classes will look
like this from now on.

If you wish the getter or the setter to include more functionality, not just
reading or writing values, you could define it manually. Let's take our example
of the full-aged problem which must be re-evaluated when the student's age
changes:

First and foremost, we'll have to create a private age field
that starts with a lowercase letter, the value will be stored there. We'll work
with this field in the getter and the setter. If you were to
use "Age", with a capital a, in the getter or setter, the program would get
stuck in an infinite loop! Why? Well, take another look at the code above (hint:
the method we are currently in has already been declared as that). You cannot
implement a custom getter and let the setter be generated automatically. They
have to either both be generated automatically or both be implemented manually.
To access the value being set in the setter, we use the value
keyword. All properties had to be implemented like this until C# added
auto-implemented properties in version 3.0. As a matter of fact, we don't need
any logic at all in the most of the properties. We'll treat the Age as
we would treat a field from now (remember it is case sensitive). Re-assignment
of the "Age" triggers the internal logic to update the fullAged
field:

object.Age = 15; // the fullAged field will update immediately as well

Seems much better now, right? From now on, we will always use properties
rather than fields since they allow us to encapsulate objects perfectly. In the
.NET framework, all public class members are properties. For
example, the Length property of a String. There's a general design guideline
that we follow that states: values that are allowed to exit a class must
be properties, and values that are internal and "non-editable",
must be private fields. Overall, we don't use public fields. The whole
class and demo app are, of course, available for download below the article. We
can now remove the fullAged checking from the constructor since we now set the
age using the Age property, and the FullAged property is updated
automatically. Let's try the code which caused issues earlier:

Download

The author is a programmer, who likes web technologies and being the lead/chief article writer at ICT.social. He shares his knowledge with the community and is always looking to improve. He believes that anyone can do what they set their mind to.

The author learned IT at the Unicorn College - a prestigious college providing education on IT and economics.