Friday, February 3, 2012

Careful with Abstractions

Browsing around MSDN the other day, I bump into the following paragraph:

"The order and types of binding elements in Bindings are significant: The collection of binding elements is used to build a communications stack ordered according to the order of binding elements in the binding elements collection. The last binding element to be added to the collection corresponds to the bottom component of the communications stack, while the first one corresponds to the top component. Incoming messages flow through the stack from the bottom upwards, while outgoing messages flow from the top downwards. Therefore the order of binding elements in the collection directly affects the order in which communications stack components process messages. Note that WCF provides a set of pre-defined bindings that can be used in the majority of scenarios instead of defining custom bindings."

Most programmers understand the concept of a stack. It's a abstraction for a data structure which allows new data items to be removed in the exact opposite order which they were inserted, that is, the first element to be inserted is the last to be removed (FILO).

And most people knows what a stack is: a pile of stuff.

And the deal with it is that you can only add /remove stuff to/from the top. The text on MSDN, however, goes through great length to tells us to imagine a stack that adds to the bottom, and that the message goes from bottom to top. A upside-down stack, in other words. Whoever wrote that was so deep into abstracting his communication stack is a certain way that he forces us to think in a counter-intuitive way. It would be easier for the author to change the way he thought about it.

I used to say that some people, sometimes, are so fixed onto a solution that when the solution doesn't works, they adapt the problem. 


Whenever you are writing a technical article like this, be careful with your abstractions; They should help people understand the problem better, so if you have to explain your abstraction (instead of explaining how it relates to the concrete problem itself), something is wrong. Like code smells, if you see a upside-down stack or any other abnormality appearing in one of your texts, take the time to review it.
at 12:31 PM Labels:

2 comments :

  1. AnonymousFebruary 4, 2012 at 4:25 PM

    Hi BB

    Although I entirely agree with your main point, I think in this case the WCF team actually chose the right abstraction. The real problem here is that, paraphrasing Fowler, "Computer scientists in general have an annoying tendency to overload terms". My guess is that the stack mentioned on the documentation is not the worldly famous rockstar LIFO data structure, but the *protocol* (communication) stack . This is exactly what happens with the TCP/IP stack, where the incoming packets flow upstream from physical to application layer, and outcoming packets do exactly the opposite.

    Thanks for the post, and great insight by the way.

    ReplyDelete
    Replies
    1. Bruno BrantFebruary 5, 2012 at 2:58 PM

      Hello Paulada! I've got the idea that the author is describing a communications stack, one inspired by the OSI model. However, that stack is build from bottom to top! The lowest abstraction level (the deepest layer) -- is encapsulated by the second one, and so forth. The stack is built in the common order, from bottom to top. The message, of course, run both ways.

      So the WCF team could still use a stack, but instead of describing one that builds from top to bottom, they could invert the order the layers are added.

      Thanks a lot for the comment! It's good to see someone actually reads this.

      Delete

Subscribe to: Post Comments ( Atom )