Encapsulate Context becomes Encapsulated Context.

The naming of patterns can be a tricky business. There are all sorts of rules of thumb, one can use, for example: favour and nouns over verbs, tell the reader what to build and describe what you get rather than what you do.

My first proper pattern, Encapsulate Context, didn't follow these rules. In fact, there was a lot of debate over the pattern name, if I remember rightly. I originally called it a Program State, then during the writing it became Encapsulate Exclusion Context, and when it was workshop at EuroPLoP the group felt the name Encapsulate Context was best. So it became Encapsulate Context.

Well a while back, I rrealised the name Encapsulate Context broke a good many of the rules of thumb, but I felt that it was too widely known to change.

Earlier this year, I submitted the pattern to the editors of the forthcoming patterns book Pattern Languages Of Program Design (Volume 5). The pattern was anonymously peer reviewed by two other writers, and in the best tradition of anonymous review one of these thought the name was fine, and the other one wanted a radical change.

The one who wants a change wanted the name changed on the grounds they it confuse Smalltalk programmers. Since the pattern is aimed at C++ and Java programmers this wasn't a big concern of mine. And again, I felt the naming Encapsulate Context, had a certain history.

( The book, by the way, probably won't appear until early in the New Year but you can pre-order it already Pattern Languages of Program Design 5.)

So when the book appears the pattern will be Encapsulate Context but since then, the name been on my mind more and more. Finally I decided to change it.

There is now a new version on my web site using the new name. Well, I say, a new version. Apart from changing the name, i.e. adding a single d, there isn't really any change.

Moral of the story? Embrace change, don't let the past, confine you.

Encapsulate Context is dead, long live Encapsulated Context!