Throughout my posts and in many many other articles, books, booklets and almost all (good) IT materials, you keep hearing the same over and over again, repeated almost like a mantra – “Find the abstraction and use it” – it’s good and all, but how you should go about it is almost always lacking in the explanations.
Now don’t take this as if I’m trying to dis my fellow authors – I most certainly am not – it’s just that – from my own personal experience from when I was a fledgling programmer tackling the great sea of code- people have a very hard time wrapping their heads around something so “abstract” as abstractions. I know I know, I used the adjective to describe the noun, something akin to recursion but not quite. Just leave it at that.
So what are abstractions?
Def: “abstraction is a technique for arranging complexity of computer systems. It works by establishing a level of complexity on which a person interacts with the system, suppressing the more complex details below the current level. The programmer works with an idealized interface (usually well defined) and can add additional levels of functionality that would otherwise be too complex to handle.” – wikipedia
In layman terms, an abstraction – in computer programming sense – represents the essence of the object, or more simply put: “That which it cannot do without”. It it the core of the functionality, or even more simply put: “it is that which defines the system with the least words possible”.
If you are a first time reader, then you may not be accustomed to my enforced practice of stating that programming is the craft of modeling real world events and interactions and as such, most of the principles and ideas that govern programming are based on real world paradigms, principles and examples that were taken and reapplied in code.
That being said. What are abstractions?
To better help you understand I will illustrate to you the greatest abstraction I know off, and for that we shall make a small exercise in writing.
Class Humanity Def human_being person end def person unless assign_male assign_female end private def assign_male #... end def assign_female #... end end
Now the code I have wrote is childish, but the point it’s leading to is not. So from the example I have given, you could extract the fact that the human_being is the abstraction (since it was conveniently placed in the top level and public interface) and the assign_male and assign_female methods are the complexities of the code that are built up on the abstraction.
But if you stop, just for a short moment, and think about it, really take a second and chew down, to the bone, there is an even higher level abstraction.
And if you can understand that high level abstraction, then you can really begin to contour the logic behind any and all abstractions and how they exist in the first place. If I’m still sounding mysterious then think of this.
To exist, what does a human being need in the first place? How did the human_being come to be instantiated?
“Third Planet from the sun”. It’s planet Earth.
You see, Mother Earth, in all it’s bountiful generosity and love, manages all dependencies. In it’s absence there could be no humanity. You see, Earth, as the abstraction, defines all rules, laws and objects upon which we as human beings depend upon. Small, but very important things such as air and oxygen, water and fire, plants and inanimate objects. It is the sole high level abstraction and we are the complexities built upon it. We convey specificity and application to a very vast and base set of rules.
If I lost you just now – and you might be justified in thinking that “hey, this is not coding” – you’d be right. But I am not explaining a coding concept. I am conveying to you an idea. I want you to understand the base idea upon which the “abstraction in programming” is based. If I can succeed in teaching you how to visualize the concept of abstraction, then you will never ever be bogged down navigating through your – or anyone else’s – code.
In ruby, the highest (or more commonly put “top level abstraction”) is BasicObject. You can think of it as Mother Earth. Every other object – whether predefined or defined by you – inherits from this top level abstraction.
You can think of it (and of all abstractions in general) as the environment. The one place in which all other object live in.
So the next time you are defining a class, think onto yourself. What is it that this class cannot do without, what does it all boil down to, and doing so you’ll have won half the battle in extracting abstraction. The other half is all about setting up your code on the right kind of abstractions. But more about that in another post.