London.js ( Part I )
Much has been said about the mighty Object Oriented Programming. But do we really realize it in our daily lives, or outside our laptops ?
If you think this is another travelogue about an Asian awed by the giants offered by the city, well you aren’t wrong, but there’s more than that I offer — a medley of the city and my own two pennies to it.
If you’re a developer, or have ever opted computer science 101 — then we all remember learning the much dreaded Object Oriented Programming. The stuff they would teach us under the garb of OOP, well never got in my head. But yes, it was often laced with a vocabulary often to envy a dictionary ( at least the way I was taught )
And well, who doesn’t remember the oft crammed Foobar, the classes Employee and getSalary() methods to calculate the yearly salary of the employee ?
None of this is relevant here ( and would not be recalled so as to not revive the scars of the same). But what matters is the fact that London gave me a chance to revise it. And so here am I — churning my oft mental litanies of realisation into a blog.
The prererquisites of this article are
- A prior hands on with programming languages ( probably C++ / JAVA / .NeT ) would turn this Latin to English for you
- A shot of tequila if you feel suffocated by the idea of London Tube. ( Let’s admit, it can be a bit suffocating at times ).
The mighty backdrop
London’s Tube is to London what the Delhi Metro is to the city of New Delhi, in India ( I come from there, if you may ask ). A big web of trains and tunnels spun craftily under the ever populous cities, often protruding out from the ground, but only when away from the shy corners of the city. And it would be a blasphemy to not ride the Tube in the London. Trust me. A mad medley of people, colours and cultures.
Please mind the gap. Disembark here for the Piccadilly Line Service.
Each line in the London Tube is essentially a collection of stations, joined to each other by a route. Some stations allow you to switch from one line to the other, thereby making them the interchanging stations. In other words, an interchanging station is a station where you disembark to alight another line to your destination.
My journey in the London tube began with the Piccadilly line, exactly from the Hounslow borough of London. The proposed track for the day, was to travel eastbound to the Green Park ( the Buckingham Palace ), wander the Trafalgar Square and then the Oxford Circus.
A tube train can consist of several coaches, with often six coaches in a train. The tubes everywhere ( around the world ) follow the same pattern : broad windows, automated doors, seats, handlebars and poles. And people, of course, unless they are in a yard.
And then it stuck my mind. If I were to ever share how the tube looks like to my Mac, how would I ? It can recognise ( but not interpret ) English words, and most importantly, how do we store it in its memory ? Certainly not by writing a word document and saving it. To add life to this imagination, how do I make it work in my MacBook, so that it can actually run its own Tube inside, to get a feel of it ?
Object Oriented Programming reassures that we can do so, by providing us a certain mechanism to translate the real world entities into a composition of attributes, to allow modelling. Since the days dinosaurs roamed the Earth, much has been said about OOP, and the C / C++ / Java trilogy.
Modelling a train
How do you describe a train ? In simplest of the ays, a train HAS A collection of coaches. We call this HAS A relationship as a composition ( and it is not complicated, until you’re on Facebook and seek social validation ) Which means, if I ever have to describe the template of a train, I would have to lay down the template of a coach.
We call this template, or the blueprint, of an object, as a class.
Why a blueprint ?
So, the question is, why a blueprint, and not call it the train itself ? The reason is that calling something blueprint allows us to extend its idea, and create customised instances. And this gives me the flexibility — I can, after all, create several trains following the blueprint, where I can customise their colours, or other features.
Listing it down..
So now, the deal is :
A train has a collection of coaches
A coach has a paint over it
A coach has a set of wheels
A coach has a set of windows
A coach has a set of doors
And with the ES6 magic, this is how I define my coach :
But, how do I…
Fair enough, but this is a mere template. How do I create a real coach out of this template ?
Well, that might be a bit of more hands-on to build a real coach, but we merely do this to create one in our memory of the computer :
const coach = new Coach();
We call this as instantiating a class.
Fair enough ! But, how do I let it know that it is supposed to have a set of four wheels, and four windows ?
Imagine, ( or pick it up as a DIY exercise about what all a wheel and window should have ), we have templates called as Wheel and Window for the same.
We may have a list of wheels as :
[ Bear with me, dear reader. We’re gonna rock a lot back and forth with this one ].
So, maybe now, I can send these to my methods setWheels and setWindows as :
But how does this work, as a whole ?
Fair enough, Benjamin. Good question.
You see the line #1 in the above gist, which says :
const myCoach = new Coach()
For those not hailing from the might C++ / JAVA / .NeT backdrop, this magical thing that allows us to create the instance is called as a constructor. Do you remember seeing this magical word elsewhere ?
Exactly ! The second line here.
A constructor is a default, magical method that creates a new instance of template for us. Essentially, the snippet
const myCoach = new Coach()
calls the constructor for us, and returns an instance of Coach.
The fun part is yet to come.
Let us outline the attributes the coach holds. A coach has
- A direction sense ( or that’s how I believe it is — the first coach, the last coach, and the middle coaches in between )
So now our template resembles this ( When I say resembles, it doesn’t refer to the complete snippet of code. Only a fraction of it to show the magic ) :
Also, there are a few other peculiarities that you may spot. You can often see something like this repeated across the length of the code. What is this, then ?
If you were to read it here, this is indeed a conundrum, and with further lessons, you can grasp the essence of this. However, in our context, we grasp in easier words ( and thereby saving us from extreme pronoun pestilence ) :
For us, this merely acts as a binder for all out attributes inside the context of a class, which we can access from anywhere inside the class in ES6.
We can see how this.wheels works : essentially, it picks up the context of the newly created object / instance by the virtue of its constructor, and then this behaves as if it were the object itself.
In other words, it can be used to refer to the object we haven’t created yet ! Magical, isn’t it ?
Which means, if I were to write this piece of code :
And then this :
Voila ! You’ve created three coaches. Now, we go ahead with building our own Tube train : ( Obviously, you have to add the missing pieces of class Coach to it, and create the instances, but I wouldn’t redo what I’ve done above )
A little hope we have, there !
more beautiful ways of doing this, which we would cover as we progress. But the intention of this piece was to introduce people to the idea of OOP and how you can build, or at least start building a whole city with mere few pieces of code ! :)
So now that we have our train, let’s get our platforms readied in the next sections, and get it running !
P.S. Did you count that our train has only three coaches ? :O Can you think of a way to add the remaining three coaches as well ? Or rather, make it more basic so that you can always churn out a tube train with the number of mid-coaches I give to you.