All nontrivial abstractions, to some degree, are leaky.
Like Joel Spolsky said, every abstraction will leak out some details of its implementation. Internal plumbing if you prefer.
Your system needs to publish data from a downstream service or collect it ? Your abstractions, be it the UI, public API, data models, etc. will, in one way or another, be influenced by this detail.
At its simplest expression, it will be a one-to-one implementation. 100% leaky. Take, for example, this traditional shower design.
One valve for hot water. One for cold. It’s an extremely simple design (abstraction). Entirely exposing how the internal plumbing works to our end user.
On the one hand, it makes it super easy to fix, repair & evolve. It also makes it glaringly obvious which valve is problematic when a problem occurs. One valve can also work without the other working. Resiliency!
The downside now. Well, the UI is not quite perfect. Want hotter or colder water? You always need to figure out how to balance out the two.
Here is an abstraction that leaks fewer internal details. On the plus side, you get an intuitive user interface. Want it colder or hotter? Simply move the level in the appropriate direction.
This design comes at the cost of the extra part or layer that converts the plumbing to the desired interface. Still a bit leaky, though. By convention, cold is typically on the right, hot on the left. But less so than the previous design. And a single point of failure. Engineering is about tradeoffs remember 😉 ?
After a few years of staleness in design, marketing steps it. They want to sell an I.O.T, A.I. driven, voice-recognizing, weather connected, facial recognizing SHower Information Terminal (SH.I.T™️)
This one is the one that leaks the least information about the implementation. It’s the most abstract!
That being said, IMHO, it’s the worst of all abstractions. As a user, I could not care less about the actual degrees, be it Celsius, Fahrenheit or Kelvin of my shower. I just want it either hotter or colder, in relative terms.
And don’t get me started on the complexities introduced by the design of this monstrosity. The need to bring out electricity alongside water to the shower. The software bugs. The software updates. The end of support. Wouldn’t want one even if given to me for free. Hard pass.
The same principles apply in software. All abstractions come at a cost.
When designing your solution, weigh in the benefits of the abstraction to your customers/clients/users/callers. But DO contrast them to their cost and how their design impacts your options in the future. No one (A.F.A.I.K) can predict the future. Early abstractions are often much worse to evolve than simple, perhaps leaky ones.
And one word of caution. Don’t let an AI generate your abstractions, UI, public APIs and such without using your judgment and experience. You may just end up with a design like the one Copilot suggested when I asked for a simple, hot/cold shower valve design.
