Sunday, July 14, 2024 10:31

Table of contents >> Objects > Access modifiers

Access modifiers

As their name suggests, access modifiers are some programming concepts that can alter the access level of something. In more complex words, access modifiers are reserved keywords which add information for the compiler, and the piece of code related to those modifiers.

They may seem abstract and confusing for now, but we will see, they are not. So: in C#, we have 4 access modifiers – public, private, protected and internal.

How do we use access modifiers? Well, we already did in a few of our examples. Remember this line of code?

or this one?

Well, there you have them! We used public and private access modifiers.

Lets explain all of them first, after which I will exemplify them.

  • Access level public – it tells the compiler that the element can be accessed from any class, property, method, etc, from the current namespace (we will learn about namespaces in the future). It can also be associated with the absence of any restriction of access. It is the least restrictive access modifier of them all.
  • Access level private – defines the most restrictive access permissions in C#. Any element that is declared using the private access modifier can only be used inside the class where it was declared. This is the default access level modifier.
  • Access level internal –  specifies that the declared elements will only be accessible from the same namespace.
  • Access level protected – elements will be accessible within its class where they are declared and in the instances of derived classes. We will learn about class inheritance in the future.

Access modifiers can only be used in front of the following elements: class declaration, fields, properties and methods. As you can imagine, they can be used to modify the access (visibility) of elements in front of which they are placed. In our previous lesson, instantiation, we added a new class file to our project, called Oven and containing among others these codes:

Then, inside our Program.cs file, we instantiated it like this:

So, once we created an instance of our Oven class, we can start accessing its members, properties, methods, etc, like for instance, the property Color, in our example. The reason why the Color property can be accessed this way, or the reason why we can assign a value to it, is because when we declared it, we used the public keyword in front of its declaration. By doing so, that property can be accessed not only inside the class where we declared it (the Oven class), but from other classes too, like we read its value from the method Main(), inside the Program class.

On the other side, the field named color was declared using the private access modifier, which means it can only be accessed inside the class where it was declared. So, we can access it perfectly from inside the Oven class:

but not from outside of it:

Notice in the above example we tried to display on the console NOT the Color property (with a capital C), which is public – therefor accessible, but the field color (lowercase c), which was declared private. Because of this, the compiler will display the following error: ‘Oven.color’ is inaccessible due to its protection level.

Since we did not yet learn about namespaces, you should not concern yourself with the internal and protected access modifiers. They are used only in special situations anyway. You should also know that there is a combination of the two, the protected internal access modifier, but for now, treat it just as a general knowledge.

It is also a good time to let you know that it is not mandatory to have our classes in individual files. So, we could have created our Oven class without creating a separate file for it, like this:

This will help you better understand the fact that classes – objects, don’t care where they are declared as long as they are inside a namespace’s body. The reason why we declared our Oven class in a separate file was because on large projects, it will help you keep your codes more organized by keeping each of your classes in separate files of your project, each having its own name. Imagine the chaos your would have if your project would have 50 classes inside your Program.cs file…

So, to conclude our lesson, now that we know multiple classes can reside in a single file as long as they are placed inside a namespace, let’s consider the following code:

So, we have two classes inside a namespace – Oven and Program. Inside our Oven class we declare two methods – TurnOn() and TurnOff(), one public, one private. Then, inside the Program class, we instantiate the Oven class, and we try to access its TurnOn() and TurnOff() methods. We do the same inside the constructor of the Oven class. The access diagram is described by the following image:

access modifiers

The TurnOff() method, being declared private, is accessible inside the class where it was declared, so, calling it inside the Oven constructor works fine. However, trying to call it from the Program class is forbidden. On the other side, method TurnOn(), being declared public is accessible to both the class where it was declared, and to the Program class.

Fine. We now know what the private and public access modifiers are. The can make some elements visible to the outside world or not. But what good does this do to us? Why should we hide stuff to the outside world in the first place? Isn’t this just an unnecessary complication?

No, not really. What if you created a game, you worked for years on it, and now you want to sell it. You have to implement some type of license and some license key system, right? And your program must also have some sort of method where you can check if a license is valid or not. If the license key is good, you call a method called StartGame(), if not, you alert the user that the license is invalid. But, if your StartGame() was declared public, so it is accessible to the exterior of your program, what would prevent an user to call it directly, bypassing your license check? That’s horrible, isn’t it? That’s why, you should declare your StartGame() method private, which would only allow it to be called from inside your program, not from the outside world.

Another reason why you should use access modifiers is because they can hide irrelevant data from the outside world. Just like in the real world, if you have a car, you are not interested by how it works, or its internal actions. You are only interested in the relevant things such as turning it on or of, driving, stirring, etc. You don’t care what gears make it possible to turn right, or how they work, you’re only interested in the action of turning right. This principle applies to programming too, where you should only expose to the outside world the relevant portions of your code, not all the inner working and calculations.

Finally, this process of hiding irrelevant data from the outside world is called encapsulation, which is a fundamental principle of object oriented programming (OOP).

If you don’t specify an access modifier, C# will internally and automatically apply a modifier, as follows:

  • Inside the methods and functions, the default access modifier is private (in fact, the compiler does not even allow you to specify an access modifier, because private is the only one available in this case)
    The above example will cause an error, because within the methods and functions, the only available access modifier is private, and we do not need to specify it:
    In the above example, the compiler knows that isTurnedOn() can only be private.
  • Within classes, the default access modifier is private:
    The above code is synonymous with
  • Within the namespace, the default access modifier is internal. In other words, this code:
    Is similar to this:

Tags: , , , ,

Leave a Reply

Follow the white rabbit