It's been a while. I've been busy working on exciting coding and writing projects!
I've missed you.
I hope you've been content in your coding endeavors. What have you learned lately?
As I've worked on more projects, I've found myself going back to the basics. Today's letter is an exercise in that. It's all about access modifiers, why we need them, and when to use them.
Access modifiers are incredibly important safety valves in C# that help developers determine which properties can be seen by other classes and their members.
We need access modifiers to reduce the chance of bugs in our code.
There are five access modifiers in C#, but I’m going to write to you today about the two most common--public and private.
The reason we need access modifiers has to do with the OOP concept of Encapsulation.
When we write classes, we want to try our best to make sure those classes are responsible for doing one thing.
And you might already be thinking, “Kasey, that sounds like the Single Responsibility Principle!” You’d be right.
Encapsulation is tied to the Single Responsibility Principle in a lot of ways.
Let me offer you an example that I hope will clear up some of the differences.
If you’ve ever worked with a poorly-managed team of people, you might have heard the expression “there are too many cooks in the kitchen,” which means too many people are trying to do too many things. They’re not observing their roles.
If you’re at a restaurant, you wouldn’t want to see the dishwasher making your cocktail.
At a hospital, you wouldn’t want the janitor handing a scalpel to the doctor (and you wouldn’t want the doctor mopping the floor before performing surgery).
Likewise, you want your software to only have access to the classes and methods it needs to perform its purpose.
The Single Responsibility Principle says, “Do this one thing.”
Encapsulation says, “...and here are exactly the tools you need to do that one thing.”
In practice, this generally means that we ought to define fields as private and provide public get and set methods to access those fields, because objects are about behavior, and their fields are about implementation details and should be hidden from the outside world.
Let’s look at this in human terms.
Think of a person—me, for example.
My name is Kasey.
You know my name is Kasey because I just told you my name is Kasey.
But my name is Kasey because somewhere, I have a birth certificate that declares that that is my name.
But you’re never going to see that birth certificate because that document is private.
Let’s translate that analogy into code terms:
I want to keep the fields of the Person class private because, like a birth certificate, I don't really think that's public domain.
However, I can still set the contents of those fields by writing methods that "tell" the program what information is going to be on that birth certificate. All I have to do is write a few more lines of code in the Program to set and write the stored information to the console.
That’s all from me today, dearest Coder.
If you want to study the simple application I used for the illustration in this letter, the GitHub repo is accessible here.
Next time, we’ll dig into the less frequently used access modifiers.
Godspeed in your keystrokes.