A specification of a data category by the set of operations that can be performed on it and the properties (behavioral semantics) those operations must satisfy, independent of any particular implementation.

Principle

Define data by interface and axioms (operations, preconditions, postconditions, invariants) rather than by memory layout or algorithms; correctness and reasoning are based on the contract between clients and implementers, permitting multiple implementations that preserve the specified behavior.

Demonstration

A stack ADT is defined by operations push, pop, top/peek, and empty with LIFO semantics: push followed by pop returns the pushed element; concrete implementations include arrays, linked lists, or ring buffers that each satisfy the same ADT contract.

Misapplication

Confusing an ADT with a particular implementation (e.g., equating the stack ADT with an array implementation) or exposing implementation details in the specification undermines portability, formal verification, and reasoning about complexity.

Consequence

Using ADTs clarifies program correctness, enables modular design and substitution of implementations, and separates concerns so that algorithmic complexity and storage tradeoffs can be analyzed independently of logical behavior.

Reversal

A concrete data representation without an abstract specification exposes implementation choices as API, leading clients to depend on representation details; the reversal accepts no abstraction barrier and couples clients to a single implementation.

Boundary

Applies to the level of specification and software design; excludes low‑level hardware wiring, physical memory layouts in embedded systems when those are part of the functional contract, and informal descriptions lacking formal behavioral properties when formal reasoning is required.

Semantic Tension

Tension with datatype implementations and object encapsulation: language runtime types or objects may conflate ADT interface with implementation; debate centers on how formal the specification must be (informal documentation vs. formal axiomatization).

Synthesis

An abstract data type is the interface plus behavioral contract that defines what operations do and the invariants they preserve—separating the logical specification from implementation choices so that multiple concrete data structures can realize the same observable behavior within stated performance and correctness constraints, with residual uncertainty about nonfunctional tradeoffs.