IoC: Inversion of Cognition

Eric has a post on Sets, since some people weren't familiar with LinkedHashSet. What I found interesting is that he quickly got into a pet example to illustrate his point.

My guess is that a lot of people skimmed the Collections API and saw LinkedHashSet, but it didn't stick with them because they didn't have a pet example. They were looking through a toolbox, seeing a bazaar of solutions, without a particular problem to solve.

In my experience, it can be very useful to "invert one's cognition" and think in terms of problems, rather than solutions. This is pretty much the same as the O'Reilly Cookbook philosophy. Both as a reader, and as a writer, it is highly effective.

Some better examples come from the Goetz (et al) book, Java Concurrency in Practice (JCiP):

Deque

I had read about a Deque for a long time. Alrighty: a double-ended queue, pronounced "deck". And that's all I knew. To be honest, I had no idea why anyone would use it, and I've taken the same hardcore data structures/algorithms classes that we all did.

Then I came across a scenario in JCiP: deques can be used for work-stealing. The scenario is multiple producers and consumers with a deque per consumer. When one consumer becomes available, it may "steal" work from the deque of another consumer, by removing a task from the tail. Bingo: deques come alive for me. I'll never forget that problem/solution, because it was expressed in terms that resonate. Note that this is more than just an example: it is a concept/problem that is genuinely solved by the tool.

Exchanger

Another part of the book talks about various barriers. It's kind of cool but I can tell that my mind is starting to go numb. Yes, if I had been writing example code that would help, but again, the text inverts the cognition for me with a nice, portable idea that I can tote around.

The idea in this case is a situation where 2 threads share a data-buffer: one writes, one reads. An exchanger is a 2-party "barrier" that allows the two parties to exchange objects in a thread-safe way. Great! Another example that I can stuff in my mental attic. Who knows when it will come in handy.

The gist: thinking in APIs is ok. Thinking in examples is better. But sometimes thinking in problems really rocks.