This is just a gist on the subject, I strongly suggest following the links herein.
"An abstract data type defines a class of abstract objects which is completely characterized by the operations available on those objects. This means that an abstract data type can be defined by defining the characterizing operations for that type." Liskov, Zilles: Programming with abstract data types
Given the informal definition above, the following pseudo-code can be seen as an ADT:
void stack_push(stack, T);
One point is that nothing is known about stack objects, except what can be inferred by the operations available for it -- in the case above,
stack_pop. Every single bit of implementation and structure detail is left to the implementation side.
Now, take an OO/python class called
Stack with the methods
def push(self, element):
If its clients know that there is a class called
Stack and they have access to it, one way to see it is that the objects are characterized by the fact that they are instances of the class
Stack whose structure contains
pop fields -- regardless of the fact that they are callable. Clients also know that they can inherit from
Stack to create something else and so on.
That is, much more is known/exposed to clients. Therefore, this
Stack type is much less abstract than the previous one (it is exposed as a concrete structure with two fields, has a class with which you can do inheritance, etc). Consequently, one could argue this
Stack type is not an Abstract Data Type conforming to the given definition. To be more strict, one would have to write something like this:
def stack_push(stack, element):
And here is a possible implementation of it (in the case below, if you already have the class above and just want to make it an ADT, it is just a wrapper):
def stack_push(stack, element):
Now the client only knows the operations and their interfaces and use them (and only them) to infer what is the type "stack". From outside, nothing is known about the actual implementation and structure of a stack (unless they breach the abstraction by inspecting the structure of the result of
Similarly, in C, you could mimic this by putting these function declarations on a
.h header file (using a forward declaration standing as the stack type, or simply
void*), and then, putting the struct definition and function implementations in the
Note on type systems: All the above, of course, are not in the context of languages with static type checking and good type systems -- such language may need to provide certain instruments to make reasonable ADTs possible. Furthermore, the way this theme is exposed in the paper cited above, "strong" type checking appears to be a matter of author preference alone; I did not see them being discussed or shown to be a requirement of ADTs -- the text actually seems to be careful in discussing type checking as something related but not essential. Plus, the explanation of a "C approach to ADT" (see above) was given by William Cook, the researcher who wrote Object-Oriented Programming Versus Abstract Data Types.  On the other hand, Cook writes:
"Abstract data types depend upon a static type system to enforce type abstraction. It is not an accident that dynamic languages use objects instead of user-deﬁned abstract data types. Dynamic languages typically support built-in abstract data types for primitive types; the type abstraction here is enforced by the runtime system."