Some excerpts below.\u00c2\u00a0 Click on the person’s name for the full content.<\/p>\n
Grady<\/a>:<\/p>\n There’s a phrase from systems engineering that applies here, the principal of least astonishment<\/a>. When an abstraction fails, a well-designed one will (hopefully) fail in predictable ways. It’s when an abstraction fails and<\/em> it fails in an unexpected way that we have evidence of a leaky abstraction<\/a>. Unfortunately, I don’t think this kind of behavior is avoidable, although it is the case that tracing down the roots of such failures and then refactoring the stuff at those roots will generally lead to a better separation of concerns. The problem is, in software, we generally never take the time to do that refactoring, and so we occasionally continue to be astonished at the most inopportune times.<\/p><\/blockquote>\n Josh<\/a>:<\/p>\n I\u00e2\u20ac\u2122ve struggled with this issue too.<\/p>\n I haven\u00e2\u20ac\u2122t come to any concrete conclusions either other than to emphasize that abstraction *costs*.<\/p>\n And not only does it cost, but it usually costs *more* than we think it does – because the person designing the abstraction is not the same person who has to invest the effort to learn how the abstraction works later on.<\/p><\/blockquote>\n