3 ms·
The principal is correct: "the bigger the interface, the weaker the abstraction." But perhaps you feel there is an second implicit, prescription: "Your abstrac
by paulddraper 3y ago
The principal is correct: "the bigger the interface, the weaker the abstraction."
But perhaps you feel there is an second implicit, prescription: "Your abstractions should be strong."
And that's not necessarily true. To every thing there is a season. Excessive abstraction is astronaut architecture.
---
The principal is a good one.
The bigger the interface, the weaker the abstraction.
That's not to say big interfaces are bad or inappropriate. It's just to say they aren't strong abstractions, so don't expect them to be.
- taeric 3y agoTotally fair. I am riffing off the idea that stronger is better. Weaker is worse. Fairly common framing, I thought But in the spirit, how is a single method "stronger?" Usable in more places, maybe? Often hides too much, such that it really can't be used everywhere. Describes more things? Well, yeah? But not in meaningful way. At this level of "abstraction," a car is indistinguishable from a bike. Certainly fair for some contexts. Not many relevant ones, though. And it is that last, that I think sticks. What is the most you can stick to an abstract set of capabilities? That will give you the most utility. It does mean the cost of implementation raises. But that is realistic?
- Makhini 3y agoIt's principle, not principal.