Abstraction and Data Structures

ABSTRACT DATA TYPES

Ok. So if you’ve spent any time at all sitting in a college level computer science course or at a local software developer meetup, you’ve probably heard of the word ‘abstraction.’ If you haven’t, you should definitely tack it onto your ‘look it up later’ list. Or just keep reading :) Today, before diving into the concept of abstraction being applied to specific topics such as data structures, let’s begin the conversation about abstraction from a bird’s eye view.

Abstraction is just hiding certain ideas/concepts/information from a party.

We, as engineers and developers, are often asked to create some sort of application to solve a client’s problem. The client says I want to put in ‘x’ and get out ‘y.’ So we develop an application where the user will interact with an interface to compute their desired output. The interface will remain separate from the actual cogs of our problem solving techniques, ie the implementation. Keeping the ‘what is happening’ (client-side) and the ‘how it is happening’ (engineer-side) separate may seem like extra work, but the benefits are fabulously helpful, particularly in relation to data types.

A data type is a set of objects that have a corresponding set of operations. This cohesive unit is considered an abstract data type (ADT) when the only way to access the operations of a data type is through the interface. Within the interface is the definition of the ADT, but nowhere is it mentioned how the set of operations are carried out, that is left for the implementation to flesh out. This carries from the design principle know as Separation of Concerns (SoC).

Plate can only be accessed after removing all of the plates on top of it.

Let’s look at an example: a stack. A stack is an ADT that adds elements to it’s memory ‘one on top of the other.’ This is very similar to a stack of plates, First In Last Out (FIFO). After you have pushed on the desired amount of elements, in order to access the last element, you must first pop, or ‘take off,’ all of the previous elements of the stack. If I wanted to write code for this ADT, I wouldn’t want my user to know how I implement the pop function, just that the pop function is available with this data type, ie the definition. So, the ‘how’ would be abstracted from the ‘what,’ which is good for many reasons, but I’ll highlight 3 here:

1. Protection. The user can’t go around messing up your beautiful algorithms.
2. Re-usability and Flexibility. The user now has the ability to use this ADT with the same stack multiple times or different stacks, without having to go through the pain of writing the implementation logic.
3. Maintainability. If I as the developer need to fix some aspect of the code, I can change just the one implementation file, as opposed to several combined files.

The above benefits are so important to building proper containers to store and manipulate data. And as we all know, data management is everything these days. So definitely use abstraction.