Embarrassing things I’ve learnt: Encapsulation
This is Micro. Seeing as how my Makers cohort has graduated and I’m no longer stuffed in a large room with twenty other unshaven trainee engineers on a daily basis, I’ve found myself rather unexpectedly without people to talk to for most of the day.
Sometimes, when an issue has you pinned and no matter how hard you stare the screen out, the laptop doesn’t relent and just give up the answer, one way of getting things moving is to articulate it. To yourself works just as well as to a colleague (or passer-by on the street, assuming you can keep up with their sprinting pace); the process is called Rubber Ducking, as in, you can be talking to your rubber duck (Micro) and get exactly the same effect. It’s really only about hearing the problem and listening to the reaction you have to your own words.
I was talking to Micro the other day, about an exercise I was running. I’m assailing JavaScript at the moment, given that it’s my intention to get into front-end to start my career, and I couldn’t understand the solution I was looking at. The author had put some steps in his development process that seemed completely unnecessary to me; however, given that this was, in fact, considered a solution, the issue was much more likely with me than the faceless dev whose work I was reading.
I turned to Micro.
“Micro,” I said, “what is this madness?”
Micro looked at me.
“Right, you can’t read. Instead of writing a method that pushes the plane into the hangar, he’s got methods for landing on both the plane and the airport. The plane has a land() function, paired with the permissionToLand() function that the airport has. Using his code, when you instruct the plane to land, the plane calls the airport’s permissionToLand method, which in turn pushed the plane into the hangar array.
“Why.”
Micro looked thoughtful for a bit and seemed as though he was about to say something, but I had a moment of mnemonic whiplash. The phantom of a memory ghosted through the wall and proceeded to haunt the slightly-damp, spider-filled attic of my mind: instances of classes should not be able to change the state of instances of other classes.
“Micro, wait. Where did I learn that? Because it sounds like a thing, and I’m pretty sure I haven’t just made it up.”
I left Micro reading about async (he’s a massive fan of ES8), and Slacked a colleague (who, on reading this, objected to being called a colleague). Sure enough, the faint burn marks of a half-consumed memory were right, and I was drifting in the general direction of Encapsulation.
Encapsulation is one of the four Object-Oriented design principles, and it simply states that the implementation of a class should be such that its state remains as unexposed as possible. State is exposed when properties and variables can be modified directly by other objects. Encapsulation:
…reduces system complexity and increase robustness by decoupling its components
(source)
When you go shopping and arrive at the till with a bag of mini Cheddars and salad cream, Tesco have to ask you to pay the bill. They don’t tell you what the sum of your basket is then waddle down to the local branch of your bank to help themselves. Your bank balance could be considered part of your state, and it would be completely incorrect for that balance to be available for modification by anyone who walked by.
You personally have to make payment. You personally have to modify your own state. Encapsulation dictates the same for any code you write. An instance of a class should have an interface that other instances can use to request modification of state, but the modification itself is something that the object does.
The reason this was a particularly embarrassing thing to realise is that this was taught in the first two weeks of Makers. Apparently I was too busy with polymorphism to actually take this onboard.
Damn it.
