See Spot Run.exe
I am a dog person through and through. I’ve never cared much for cats – their dander, their demeanor, their general lack of doing-stuff-ness. (If you like them though, that’s cool!)I love that dogs are always excited to see you and I enjoy how easy they are to please.
Above all, I love that dogs are teachable, not to say that cats aren’t, but dogs are just so easy and eager to learn.
If we ignore the time and repetitions between, training a dog largely boils down to a human-says/dog-does relationship. The fact that dogs are so teachable lends to them to great examples of a lot of the basic principles of programming.
In the past, I’ve described programming to you guys as explaining instructions to a very gullible person and I can hardly think of a more gullible being than a dog.
I have a few dogs of my own, each with their own characteristics, personalities, and names. I’ve spent a lot of time getting my dogs into routines and helping build their knowledge base. I have taught them their names and I’ve had to teach them what cues and words to look for. All of this training (programming) I’ve done is so my dogs know when to do something specific.
My dogs know that when I raise my hand as a fist and say “Sit”, they are to lower their butts to the ground and patiently sit. When I say “Go” and point a finger, they are to follow the finger and go off in that direction.
I would say that my dogs are well-programmed.
It’s taken me years of time and effort to get my dogs as well-trained as they are. Now imagine how I would feel if a friend were to come over to my house, and start to reprogram my dogs. The nerve!
My friend sees that my dog is named Sparky and decides he thinks “Manatee” is a better name. He calls my dog Manatee, and now my dog responds to Manatee and not Sparky. My friend sees that my dogs know how to sit when I raise a fist, but he decides that when I raise a fist my dogs should spin in a circle instead. All of that work training goes right down the tubes.
Now obviously retraining the dogs would take a lot of time and effort in real-life, but just imagine how chaotic that would be if anyone could just waltz right into my yard and reprogram my dogs as they see fit.
To Protect and Serve
Now let’s imagine that we aren’t talking about a dog and that we are instead talking about a program. When we program, there are certain things we want the user to be able to do and certain things we don’t want them to do.
If our program was dog.exe, I might be okay with the user telling the dog to sit, but I don’t want the user to reprogram what “sit” does. Basically, I am okay with the user making the dog sit, but I am not okay with the user deciding what the “sit” command should do.
In the case of the dog program, it might not seem to apparent why this really matters. Who cares if we make the dog spin in a circle or shake a hand instead of sit? Does it really matter?
It does. Let’s imagine if we were writing a slightly different program.
What if instead of our dog program were writing a banking program? We would probably allow our user to create an account, deposit money, and withdraw money – all of the exciting banking stuff.
Now ask yourself what if the user had free-reign over how those functions operated? What would happen then?
A World Without Encapsulation
If that were the case, the user could easily jump into our program and rewrite the “withdraw” function to instead add money into their account. Or maybe they reprogram the “deposit” function so that when they deposit money it actually withdraws that money from a random users account and deposits it into their own.
Now I’m sure a lot of you out there are thinking “Man, that’d be awesome”, but as a programmer you’d very quickly be out of a job. And we don’t want that, right?
Unfortunately, the idea that people out there might want to reprogram and change your code for malicious reasons is a very real possibility. Because of that, programmers like yourself need to take the right steps towards protecting your code.
You need to think of your code as a sort of stage play and the user as the audience. They can enjoy everything that is on stage but you wouldn’t want them meddling with the costumes, stages, scripts, and effects that are controlled behind the scenes.
This idea – the idea that we do not want to give folks more ability in our programs than what they need – is called encapsulation.
The full idea of encapsulation goes a step further. Encapsulation is not just stopping the user from doing stuff they shouldn’t be doing, it is also stopping other pieces of the program from “messing with” the pieces that it shouldn’t have access to.
Encapsulation is immensely important because we need to protect our code from being misused and mishandled the best that we can. So the question becomes, how do we protect our code?
We achieve this goal by hiding as much of the information in our code behind “locked doors” as possible. We then only give the keys to the people or pieces of code that absolutely need access.
Encapsulation as a Stage Play
If we were to use the analogy of your program being a stage production again, think of the user as the audience and each class within the program as an actor.
The idea of encapsulation at work would be if each of our actors (classes) only received a script with just the portions of the play that they are in. If a certain actor has a scene (function) with other actors, then their script would also include that actor’s lines. If, on the other hand, there were two actors who shared no scenes together, then neither’s script would have any of the other’s lines.
I can take this analogy a step further. If multiple actors (classes) share a scene, they may know each other’s lines but they do not act out each other’s parts. In a real play, the actress playing Juliet may know Romeo’s lines, but she wouldn’t go on stage and start reciting them.
Classes with proper encapsulation work the same way – each class knows how and when it relates to another class, but it doesn’t really know (or care) how. All it cares is knowing that the two of them can act out their part together, without either trying to step in on the other’s role.
Keep in mind, encapsulation isn’t done for the sake of being super secretive and mysterious with our code. We aren’t trying to “stop” the audience from knowing how things work behind the scenes (most of the time).
We encapsulate because we want to be safe with our code. Proper encapsulation keeps our code safer from intruders who want our code to work in ways that it wasn’t meant to, and it also works to help us as programmers be sure that our programs do in fact work the way we intend them to.
The Keys To Encapsulation
Encapsulation is immensely important because we need to protect our code from being misused and mishandled the best that we can.
The rule of thumb when it comes to encapsulation is to make everything in your program as minimally accessible as possible.
Some folks like to program with everything “open” and then go back through and start locking information down. I personally shy away from this practice for a few reasons.
For one, it will require you to needlessly go back through every bit of code. If we do it “right” the first time, our double-checking is much easier. Secondly, this habit also leaves you open to poor encapsulation if you fail to double-check something. If you go back and only remember to “lock down” 80% of your code, you’ve left 20% open for attack.
Here’s what I recommend:
Start out by making everything completely “locked down” (“private”) and open bits and pieces up as necessary.
In my article about IDEs, I mentioned how some are smart enough to pick up on mismatches in your code. IntelliJ is one that does a great job of letting you know when your encapsulation is out of whack. It notifies you if it finds where an access mismatch will stop the program from running.
Even better – IntelliJ will also let you know when certain attributes can be made more private, locked down even further.
Where Do We Go From Here?
Pretty soon, I’m going to post a big article about the different levels of access within Java programming. These different levels are set using “access modifiers”. Stay tuned for that!
The interesting thing about encapsulation is that telling our program what is off-limits isn’t enough. We have to also bring functions and methods into the mix. Those concepts will work as the go-between for the stuff that’s off-limits and the stuff that we want to do. This is where Getters and Setters come into play, which are big concepts themselves. It may sound like a lot, but I promise, I will make it simple!
Encapsulation is one of those topics that took me a while to really grasp. It is an umbrella term of sorts, as there is no singular way to encapsulate. Stay tuned for that in the very near future!
For the time being, take some time to pick through your code. Ask yourself, If someone wanted to make this do something different, could they?
If the answer is yes, it’s time to start taking your encapsulation seriously.