Abstraction means exposing a simple interface that describes what something does
while hiding how it does it.1 When you call sort(), you depend on the promise (“returns
sorted output”), not on whether it uses quicksort or mergesort.
What it buys you
Good abstractions shrink the amount you have to hold in your head: instead of reasoning about a thousand lines of filter math, you reason about a single operation with a clear name and contract. They also keep coupling low — callers depend on the what, so the how is free to change without breaking them. This is the foundation of object-oriented interfaces, declarative styles, and most design patterns, and it underpins the dependency-inversion idea in SOLID.
Information hiding and encapsulation
Abstraction only holds if the internals stay genuinely hidden. Information hiding is the discipline of keeping a module’s internal state and helpers private, exposing only the interface; encapsulation is the language mechanism that enforces it — private fields, unexported names, access modifiers.1 Anything you expose, someone will depend on, so the rule of thumb is to expose as little as possible. A small public surface is a small set of promises you must keep, closely tied to the language’s type system and visibility rules.
Leaky abstractions
No abstraction is perfect. A leaky abstraction is one whose hidden details surface anyway, forcing the caller to know what was supposed to be hidden — a “local file” interface that mysteriously stalls on a network path, or an ORM you can ignore until a query is slow. Joel Spolsky’s “Law of Leaky Abstractions” holds that all non-trivial abstractions leak to some degree. You cannot eliminate leaks, but you can manage them: document assumptions, surface failures explicitly rather than misbehaving silently, and keep the abstraction honest about what it promises.1
Sources
-
Abstraction (computer science) — Wikipedia, for the what-vs-how definition and the roles of information hiding and encapsulation. ↩ ↩2 ↩3