Abstract Data Type Concept

Good day, habravchane!

The following post is a presentation of my thoughts on the nature of classes and ATD. These thoughts are complemented by interesting quotes from software development gurus books.

Introduction

Let's start with the fact that we smoothly approach the definition of ADT. ATD, first of all, is a data type, which means the following:
availability of certain available operations on elements of this type;
and data on which these operations are performed (range of values).

What does the word "abstract" mean? First of all, the concept of “abstractness” means focusing on something important and, at the same time, we need to take a break from the unimportant details at the moment. The definition of abstractness is well explained in the book Grady Booch (“Grady Booch”). The definition sounds like this:

Abstraction is the selection and imparting of a set of objects of common properties that define their conceptual boundaries and distinguish them from all other types of objects.
In other words, abstraction allows us to “shed light” on the data of objects we need and, at the same time, “obscure” those data that are not important to us.
')
So, what will happen if we merge the concepts “data type” and “abstraction” together? We will get a data type that provides us with a certain set of operations that ensure the behavior of objects of this data type, and this data type will hide the data with which this behavior is implemented. From here, we come to the concept of ADT:

An ADT is a data type that hides its internal implementation from clients.
Surprisingly, by using abstraction, the ADT allows us not to think about low-level implementation details, but to work with the high-level essence of the real world (Steve McConnell).

I believe that when developing an ADT, you first need to define the interface, since the interface should not depend on the internal data representation in the ADT. After determining the operations that create the interface, you need to focus on the data that will implement the specified behavior of the ATD. As a result, we get a certain data structure - a mechanism that allows you to store and process data. At the same time, the beauty of ADT is that if we want to change the internal presentation of data, then we will not have to wander around the entire program and change every line of code that depends on the data we want to change. ATD encapsulates this data, which allows you to change the work of objects of this type, and not the entire program.

Advantages of ATD

The use of ADT has a lot of advantages (all the described advantages can be found in Steve McConnell’s “Perfect Code”):

• Encapsulation of implementation details.
  This means that once we have encapsulated the details of the implementation of the work of the ADT, we provide the client with an interface with which he can interact with the ADT. Changing the details of the implementation, customers' perception of the work of the ADT will not change.

• Reduced complexity.
  By abstracting the implementation details, we focus on the interface, that is, on what ADT can do, and not on how it is done. Moreover, ATD allows us to work with the essence of the real world.

• Restricting the use of data.
  Using ADT we can be sure that the data representing the internal structure of the ADT will not depend on other parts of the code. At the same time, “independence” of ATD is realized.

• Highly informative interface.
  ATD allows you to present the entire interface in terms of the entities of the subject area, which, you will agree, increases the readability and informativeness of the interface.

Steve McConnell recommends that low-level data types, such as a stack or a list, be presented as an ADT. Ask yourself what this list represents. If it is a list of bank employees, then consider the ADT as a list of bank employees.

So, we figured out what ADT is and named the advantages of its use. Now it is worth noting that when developing classes in OOP, one should think, first of all, about ADT. In this case, as Steve McConnell said, you are programming not in the language, but using the language. That is, you will be programming to go beyond the language, not limited to thoughts in terms of arrays or simple data types. Instead, you will think at a high level of abstraction (for example, in terms of spreadsheets or lists of employees). A class is nothing more than an addition and a way to implement the concept of ATD. We can even present a class as a formula:
Class = ATD + Inheritance + Polymorphism.
So why should they think about ADT when developing classes. Because, first we have to decide which operations will make up the interface of the future class, which data to hide, and which data to provide open access. We need to think about providing a highly informative interface, ease of optimization and code verification, as well as how to provide the right abstraction so that we can think about real world entities, rather than low-level implementation details. I believe that it is after the definition of ADT, we should think about the issues of inheritance and polymorphism.

It is worth noting that the concept of ATD has found a wide application in the PLO, because it is this concept that complements the PLO and allows you to reduce the complexity of programs in a rapidly changing world of software requirements.

I wrote this article to draw the attention of developers to ADT in order to improve the quality of work and software development.

Used sources:

Steve McConnell - “Perfect Code”;
Robert Sedgwick - "Algorithms for Java."