Abstract Data Type and Information Hiding

An abstract data type (ADT) describes permissible operations and their behavior without specifying a concrete memory organization. The visible interface remains stable, and the implementation can be changed.

In Java, this is often modeled as an interface plus a class. Callers only see method signatures and documented contracts (preconditions, postconditions). Internal fields remain private.

Example: A Stack ADT requires push, pop, and isEmpty. Whether the elements are in an array or in linked nodes does not concern the caller, as long as LIFO is maintained.

Edge case: If a method violates the contract (pop on an empty stack), the specified error behavior must be triggered, such as an exception.

Interfaces like List, Queue, or Map in the JDK and in backend APIs separate the contract from the implementation. Clients depend on the ADT; teams can replace ArrayList with another List implementation without rewriting the callers. The same pattern is seen in microservices: public API remains stable, while internal storage is interchangeable.

Depth

An abstract data type is described by its observable operations and their laws. Whether its data resides in an array, a list, or a file does not belong to the contract. Thus, an implementation can be replaced as long as all promised effects are maintained.

Information hiding limits the number of states that external code can create. A representation invariant like 0 <= size <= capacity only needs to be ensured within the class. This local burden of proof is a crucial reason for encapsulation.

The boundary of abstraction also serves as a boundary for complexity guarantees. An operation can remain functionally equivalent while switching from constant to linear runtime. Therefore, relevant runtime guarantees belong in the documented contract.

Difficulty levels

1. Distinguishing public operations from internal fields.
2. Formulating a representation invariant and verifying it against methods.
3. Examining two implementations for behavioral and runtime equivalence.

Pitfalls

Getters and setters do not automatically create a good abstraction. If they expose every internal state unchecked, the representation effectively remains public.