Describing available operations
A queue can be described through creation, insertion, removal, and emptiness operations without exposing whether it uses an array or lists. An abstract data type specifies this operational contract: which values can be created and how operations should relate. The purpose of the data is separated from one storage layout.
Hiding representation and preserving rules
Unrestricted access to internal nodes or counters can create states that operations cannot safely handle. Hiding the representation channels construction and updates through an interface. OCaml signatures can expose a type name and its operations without revealing the definition, providing a language-enforced boundary rather than relying only on naming conventions.
Changing an implementation
Different queue representations can share an interface while preserving first-in, first-out behavior. Their time and space costs can still differ, so unchanged client code does not imply unchanged performance. A useful contract must also explain cases such as removal from an empty queue; abstraction does not replace behavioral specification.
Abstract types are not synonymous with classes
A module system can provide abstract types without making each value a class instance, and a class need not hide all representation details. These mechanisms overlap in encapsulation but are not identical. ML-style theorem interfaces illustrate the boundary: clients can combine permitted constructors without freely fabricating the hidden representation.