Advertisement
If you have a new account but are having problems posting or verifying your account, please email us on hello@boards.ie for help. Thanks :)
Hello all! Please ensure that you are posting a new thread or question in the appropriate forum. The Feedback forum is overwhelmed with questions that are having to be moved elsewhere. If you need help to verify your account contact hello@boards.ie

Leaking Abstractions

Options
  • 06-02-2003 5:08pm
    #1
    davej
    Registered Users Posts: 1,186 ✭✭✭


    This is an interesting article on "Leaky Abstractions".

    http://www.joelonsoftware.com/articles/LeakyAbstractions.html


    It's basically about how many high level languages/systems attempt to wallpaper over things but sometimes the wallpaper rips and the complexity spills out. The article argues that this leads to a paradoxical situation in which, for example, many of the new lauded code-generation tools can cause difficult problems when the abstraction leaks.

    The assumption of "not having to worry about the lower level details" often causes serious problems especially in areas like efficiency and flexibilty. Anyway read it for yourself and see what you think.


    davej


Comments

  • Options
    #2
    Talliesin
    Closed Accounts Posts: 9,314 ✭✭✭Talliesin


    One thing that could be added to what he says above is the problem of people mistrusting the abstraction once they know of the leak.

    In some cases that is a good design decision (the ASP.NET button thing should be considered broken, and you should always hand-code instead).

    Often however it leads to people not using useful abstractions when they probably should (using char* instead of std::string would be a regular example) just because there are some cases where using the abstraction will cause problems.

    Also I wouldn't count the case of SQL being slower to query with WHERE A=B AND B=C than with WHERE A=B AND B=C AND A=C as a leak in the abstraction, it's a bug in the code implementing the abstraction (which should optomise away issues like that) rather than a leak in the abstraction itself.


  • Options
    #3
    davej
    Registered Users Posts: 1,186 ✭✭✭davej


    Also I wouldn't count the case of SQL being slower to query with WHERE A=B AND B=C than with WHERE A=B AND B=C AND A=C as a leak in the abstraction, it's a bug in the code implementing the abstraction (which should optomise away issues like that) rather than a leak in the abstraction itself.

    Yes I take your point with that specific example but I think the more general argument is that there are always going to little subtleties that an abstraction will not be able to cope adequately with. And if you did attempt to code for every contingency you'd end up writing the very code you are trying to abstract for. It's a question of balancing a fine line I think.

    davej


Advertisement