A leaky abstraction reveals implementation details instead of hiding them. It may solve part of a problem, yet make the broader design harder to change. Rather than removing complexity, it adds complexity that clients must understand and work around. section 2.1.2 section 2.3
Leaks are especially damaging during refactoring. Implementation concerns seep into client code, then spread across a project, so a change intended to improve the whole design meets dependencies on the old details. section 2.1.2 section 2.3
Layering abstractions until they leak
C++ templates illustrate the risk: a developer can build an elaborate abstraction to solve a problem, but awkward syntax and fragile layers create a “house of cards.” Adding abstractions over abstractions becomes over-engineering when the resulting structure exposes its own traps instead of presenting a stable design. section 2.1.2
Functional idioms, higher-order functions, and mathematically inspired concepts can support powerful abstractions, but none are automatically leak-proof in practical software engineering. Judge an abstraction by whether it reduces complexity and preserves freedom to change the design. section 2.1.2 section 2.3
