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.