One of the biggest challenges for any developer, comes from the immense number of definitions which a person must learn, in order to understand concepts; from basic to complex. To make matters worse, many of these definitions don’t immediately make sense, even to those of us who have the advantage of speaking English at a native level.
I normally encourage people to attempt to“know it within the code,” so that a person need not rely on such jargon (or a teacher’s ability to explain it, which may be limited). However, even I begrudgingly admit to the fact that there are a few special words, which point to special concepts, which any developer should be familiar with.
I do believe that the two words I’ll be focusing on in this article, and more importantly the concepts which they point to, do qualify as such; especially for those working within object oriented software systems. Those words happen to be:
Abstaction: Not Quite The Real Thing, But Often Good Enough
To begin with, let me explain what I think about the word abstraction, outside of the context of programming. At the risk of getting philosophical for a moment, I define an abstraction as a less detailed representation of an object (I could also use the word “thing” instead of “object”).
In order to explain what I mean here, let’s imagine that we’re two cave people having a conversation, and I’m trying to describe to you, that I found out that a particular kind of snake is incredibly poisonous.
Since our communication is limited to a series of grunts and pointing gestures, I decide to just draw a picture of the snake on a rock.
The snake that I hypothetically drew, is an abstraction. It’s a less detailed representation of an object, which is detailed enough that I don’t need to endanger anyone by showing them the real snake. Everyone’s happy; we all grunt in approval.
Implementation: The Real Thing
Now, going by the previous analogy, every snake in the world which looks like my abstraction, is technically an implementation of the snake abstraction. However, as developers, we build things, and people don’t build snakes.
So, let’s look at implementation from a different analogy. Suppose that we’re building a house, based on a blueprint (abstraction). You might say, that the building materials, such as the boards, nails, screws, roofing, concrete, etc., are the implementation of the blueprint. It has more details; it is in reality.
Once it has been constructed, it looks something like this:
An important point here, is that implementations can be different. For example, if we implement this house with nails alone, it’s going to be incredibly difficult to fix our mistakes, or add anything to the house later on. It turns out that this principle manifests itself when we build software as well.
Back To Software Design
To return to object oriented programming, the abstractions which people will typically refer to, generally take the form of interfaces, abstract classes, or protocols. They all contain details and information which must explicitly be represented in any object that inherits such details from the abstraction, and this is typically enforced by the compiler.
When an object talks to an abstraction instead of talking directly to an implementation, something magical happens. The object, no longer cares who or what it’s going to be talking to; but it knows enough about who or what is behind the abstraction, for them to still communicate at run time.
To give a different spin on an analogy which I first heard from Robert C. Martin (consider checking out his work), suppose that you divide an object oriented system into distinct architectural layers, based on three criteria:
- Code which draws things on the screen
- Code which manages I/O devices such as databases, network adapters, system services, and so forth
- Code which coordinates the flow and logic of the above two layers, in order for our application to make money or solve a problem (typically, but not always, do those goals seem to go together)
Assuming that your abstractions have adequately covered everything your application will need to do (which is rarely the case, but this is a hypothetical point), you could build the objects in a given layer, completely independently of the other layers, and verify it’s functionality 100% through tests (that’s a topic for another article though).
In fact, you could have three separate developers build each layer of a single application, and none of them would have to worry about breaking each other’s code, or even talking to each other, to build a working application. That’s a neat thought, isn’t it?
Some More Thoughts (And Words):
There’s a lot more to abstractions and implementations than what I explained above, but this wasn’t meant to be a practical discussion. My goal was to hopefully give you a perspective on these words, so that you can start to consider what they mean with regard to building more flexible and modular computer systems.
Since the concepts I pointed to have far deeper implications than just computer systems, I will share some words in the English language below, which I believe point to the same dichotomy in other contexts. A wise monk once said, sometimes only a single word is enough.
Ideal versus Actual
Abstract versus Concrete
Idea versus Thing
Phenomenological versus Physical
Now that I’m done being philosophical, let me ruin the mood by asking you to inflate my social media platforms or give me money if that article was useful. Either way, thank you for reading.
Follow the wiseAss Community:
Support wiseAss here: