This is the second part of the OOP primer series, where we discuss the concept of Abstraction and how it pertains to removing details of how an object works.

If there are any comments please feel free to email me.

Abstraction

When we think of abstraction, we usually think of “abstract thoughts”, such as thinking “out of the box”, though in OOP abstraction is more so keeping things “in the box” more so than out of it. Through Abstraction we as programmers want to hide the details that may make up our programs so that the end-user doesn’t have to deal with them when running the programs; the programs should just work. Going back to our car example, when we press the gas pedal, we don’t need to worry about how much combustion is going on in the engine for the car to start to drive, all we care about is the car driving. When dealing with Abstraction, we want to hide all the unnecessary details when it comes to how the objects themselves work from the end-user because it is not the end-users responsibility or business to know how it all works, that is up to the programmer.

Abstraction of the underlying mechanisms of objects is important because it leaves it to the programmer to create the functionality necessary for a certain object to perform the task that needs to be done. It doesn’t introduce to the end-user all the why’s and how’s and whats of an object’s certain functionality, instead, it only produces the necessary output for its function. Abstraction within OOP is the “black box” in which all the mechanisms of the object’s functionality work but the user doesn’t have any clue what goes on inside of it. The “black box” can take in an input, but it most definitely will produce some type of output given its functionality whether that output is shown to the user or the output will take place within the black box itself.