Abstract Data Types and Program Modularity

We have been on a long journey through abstraction since the Programming 1 course. Object oriented programming (OOP), Interfaces and Polymorphism. Abstraction (in the general concept) can be something hard to understand initially because it requires the ability to generalize a behavior and break a process down into its building blocks, detached from a specific problem or content.

The task is hard, the concept is relatively simple and the consequences are huge. We are learning that a significant part of what makes computers so powerful and one of the driving forces that are changing our modern society is this abstraction capability. Abstract data types (ADTs) come to add another tool to our understanding of how these machines function and how they adapt so quickly and seamless to the multitude of programs that we use in our everyday life.

As the book beautifully summarizes, an ADT “refers to a set of possible values and a set of operations on values, without any specification of how the values are to be represented or how the operations are to be implemented” (Eck, 2016, p.444). When I first read this sentence it did not help much because it felt too abstract. Funny. It is hard to grasp because of what I mentioned in the beginning: it requires the ability to generalize a behavior. A lot of things that we learn in our lives are given as “natural rules” and then it is hard to deconstruct them later. One good example is the Postfix Expressions subchapter. It was the first time that I saw the possibility to write an simple mathematical expression in a different order like 2+(15-12)*17 to 2 15 12 – 17 *. It is not just about having fun with the numbers, it is actually an easier way to work with them from a computational perspective. They do not require parentheses or precedence rules!

This subchapter complements the Stack and Queues concept. We might be tempted to focus on how Stacks and Queues are implemented in Java, but actually this is all about the behavior (semantics) of the data. A Stack can be thought of as a pile of dishes to clean. After dinner you keep adding dirty plates on top of another. When you start cleaning you do not remove from the bottom or the middle, you start by the top (I do like that, do not want to risk breaking all my plates by doing in a different order). It follows a policy, defined as last in, first out (LIFO). The Queue can also be simply thought of as a queue to enter a club. First in (the line), First out (in the club). Imagining using a Stack policy in a club? Not fair at all!

Everything presented above comes together in the context of programming by the fact that you separate the data structure from the policy to handle it. This is very powerful for program modularity, because you can then change and optimize the way that you handle the actual data without affecting the data itself and without having to know the details of the ADT implementation (a.k.a. encapsulation). This also gives flexibility to use and apply with ease specific ADTs in specific contexts where they might work better (Akhtar, 2011). Some algorithms work well with some data structures while others work better with the rest. Stacks for example are used in subroutine calls; Queues for others, like web server requests, processing each one in order.


Akhtar, A. (2011, September 11). Data Structure & Application. Retrieved December 05, 2017, from

Eck, D. J. (2016). Programming: introduction to programming using Java(7.0.2 ed.). San Francisco, Calif: Sohobooks

Leave a Reply

Your email address will not be published. Required fields are marked *