通过

Framework Design Guidelines: Avoiding Abstractions

  • 项目

Continuing in our weekly blog post series that highlights a few of the new image[5]_thumb[2]_thumb[2]_thumb_thumbadditions to the Framework Design Guidelines 2nd edition..

This content is found in the Principle of Self-Documenting Object Models section of Chapter 2: Framework Design Fundamentals. I love the war-stories that our annotators provide here.

AVOID many abstractions in mainline scenario APIs.

KRZYSZTOF CWALINA

Abstractions are almost always necessary, but too many abstractions indicate over-engineered systems. Framework designers should be careful to design for customers, not for their own intellectual pleasure.

JEFF PROSISE

A design with too many abstractions can impact performance, too. I once worked with a customer who re-engineered its product to incorporate a heavily OO design. They modeled everything as a class and ended up with some ridiculously deeply nested object hierarchies. Part of the intent of the redesign was to improve performance, but the “improved” software ran four times slower than the original!

VANCE MORRISON

Anyone who has had the “pleasure” of debugging through the C++ STL libraries knows that abstraction is a double-edged sword. Too much abstraction and code gets very difficult to understand, because you have to remember what all the abstract names really mean in your scenario. Going overboard with generics or inheritance are common symptoms that you may have over generalized.

CHRIS SELLS

It’s often said that any problem in computer science can be solved by adding a layer of abstraction. Unfortunately, problems of developer education are often caused by them.

Comments

  • Anonymous
    December 01, 2008
    PingBack from http://blog.a-foton.ru/index.php/2008/12/02/framework-design-guidelines-avoiding-abstractions/

  • Anonymous
    December 01, 2008
    Guys, you're doing nice business by publishing interesting info at this site. But you sometimes just clutter your page space by posting installments of the above kind. These small fragments don't make much sense when just taken from arbitrary places in the original book. After reading the second installment from 'Idioms...' book I have a feeling that info not complete and in its current it brings no value to me. Probably, other readers will join my opinion. Don't make us think that we're reading nothing but small, single page-size long portions from, say, 'Peace and war' kind of books.

  • Anonymous
    December 02, 2008
    The comment has been removed

  • Anonymous
    December 02, 2008
    Yeah, I think they're fine. As you said, the book is really a bunch of small nuggets like that. It is written in a much different style than most books you'll see around lately, so maybe it throws people off. While I find the above perfectly fine, I may be biaised because I -have- read the book from cover to cover (well, the original edition anyway). Maybe sticking to the DOs and AVOID and stuff from the book may be easier for those who did NOT read it to grasp, but thats just a guess.

  • Anonymous
    December 02, 2008
    Hello Brad, This book is really valuable to me and my career. Your weekly posts on the book, keep me motivated to read the book further. Also its a kind of checklist and status check. I am a new Architect and I need to learn as much as I can. Specially the annotations or nuggets whatever you call, they are most helpful. As they come from people who really practice it. This fills the Gap between theory, practice and real world situations The best thing in all of these writing is that people like me can learn from people like you, who have faced tough situations. We should take your experience as base and lay down Architecture for future. Please carry on with writing weekly posts :) Thanks Shail

  • Anonymous
    December 02, 2008
    The comment has been removed

  • Anonymous
    December 02, 2008
    The comment has been removed

  • Anonymous
    December 02, 2008
    Brad, I've just read what I wrote yesterday in my post and I found it a bit of agressive style:) That's not true though it may look like that, so accept my appologies. Anyway, to make these nuggets more useful in terms of making the readers take well-sound decisions whether to buy the book or not, maybe you select more 'self-contained' nuggets? I mean here nuggets that when taken out of the overall context look still self-contained, i.e. not requiring referencing the rest of the book for the complete picture. Personally, I'm willing to purchase that book as I've read many installments from the first edition. But if I only had have these nuggets I'd be hesitating much when considering purchase. Thanks, Brad!

  • Anonymous
    December 03, 2008
    I think Jeff's comment on heavy OO design is misleading. It implies that the cause of the slowdown was somehow "overdoing" OO. Heavily focusing on OO should lead to performance and cost benefits. If you get something else out of it, your design is flawed, not the approach. OO never implies that you are ought to create massive hierarchies and extremely complex models. I think the customer in question just tried to apply design patterns without understanding how to use them.

  • Anonymous
    December 03, 2008
    You have got to be kidding right? Software is about abstraction. Abstraction is the reason we are not programming usking ones and zeros. Abstraction is the place where we can improve the way we do things today and make them better. Abstractions makes the code easier to understand, easier to split up and easier to test. Avoiding abstractions gives us the opposite. Some abstractions are not very good, I must admit. (like renaming ArrayList to List. giving an abstract name to a real class is misleading i think. The real abstraction is the IList which was there in the first place). Abstractions is what makes us able to simplify code and realize where we can improve. JEFF PROSISE claims that abstraction is bad for performace. It might be so, but lack of abstract is also bad for performance. Without abstractions you will have much more code. It will be difficult maintain and you will quickly end up with something that performs badly. I think you mean that one should avoid bad design and not abstractions. :)

  • Anonymous
    December 03, 2008
    Rune Juhl-Petersen is 100% right here, however to be fair to the authors, I think the point is simply 'poorly concieved, executed, misguided or simply stupid' abstraction. This post however is one of the worst titles I have seen this year, as I thought it was a joke. I'm sure someone I work with may may try to argue this 'position' in a future design session. Usually the same people optimizing while they code anything. If anything the title should be 'The imperitave for intelligent abstraction'. Damon

  • Anonymous
    December 04, 2008
    "name" is not a valid attribute of the "pre" tag, it takes some tweaking, but you can get the code highlighting to work without breaking standards. generall what i do is something like <pre class="code csharp"> and have it look for call pre tags with a class of code.    

  • Anonymous
    December 04, 2008
    I like the "nuggets" as I find the information useful by itself and easy to quickly consume.

  • Anonymous
    December 04, 2008
    The comment has been removed

  • Anonymous
    December 20, 2008
    VI6xdy  <a href="http://lyuznyzhvbnx.com/">lyuznyzhvbnx</a>, [url=http://jdmhfhpqtsvs.com/]jdmhfhpqtsvs[/url], [link=http://djyckoxgvtmw.com/]djyckoxgvtmw[/link], http://jkdvzqgqlzyz.com/