discussion group while on a project at MSA. I was in a team of about 50 Java developers, and there were a few other dilletantes like me who knew Design Patterns enough to throw out the buzz words, but didn't really know Design Patterns. I figured there's safety in numbers, so we slogged through together.
Design Patterns
is a great choice for a technical reading group. First, they're non-cumulative, so if someone misses the first 10 meetings, they can still jump in at 11 and contribute. They're also extremely practical. A developer can't go a week without seeing an instance of a good 'ole Singleton or Factory or Command. And lastly, there are plenty of references, so even the stingy can get their hands on something to read.
Community
Tending to the community aspect of the group was as important as the patterns themselves. Cultivating Communities of Practice has some good suggestions for keeping the group "alive", engaged, and responsive. Robert Putnam also talks about the benefits of communities in Bowling Alone
and Better Together (two excellent books). In my experience, I saw that just through some bi-weekly meetings about patterns, strong connections would form between people that otherwise wouldn't be talking. Through these connections other non-pattern information flowed - and not just about last week's Steeler game, but good practical project related stuff. Community is vital for any development project, and these reading groups were great for supporting this.
Discussion Format
Joshua Kerievsky lays out a nice format of a design patterns study group in A learning Guide to Design Patterns. Within the discussions, someone plays the role of facillitor, essentially the gadfly that peppers the group with questions, keeping the socratic dialogue alive. It was not a presentation, and this was important. We were all equals in our knowledge, so a simple conversation style let us share information efficiently and stay engaged.
Another important element was the cadence or rhythm works of the group. Every Wednesday at lunch we'd meet - and there were no problems with expectations or coordination. If you couldn't make it, you came to the next one. No problem.
Also important was preparation. Here are some questions that I created to guide the discussion:
|
Abstract Factory Adaptor Bridge Builder Chain of Responsibility Command Composite |
Decorator Facade Factory Flyweight Iterator Interpreter Mediator Memento |
Observer Proxy Singleton State Strategy Template Visitor |
Resources
Of course the best resource is the timeless Design Patterns
book, by the Gang of Four. A couple other books take on the GoF patterns as well: Patterns in Java, Patterns in Java: A Tutorial, and Head First Design Patterns (poster).
A number of web sites are just as helpful, like the C2 Wiki and dofactory.com. Lastly, you can't dig into patterns without reading a conversation with Erich Gamma, Three Sources of a Solid Object-Oriented Design, or The Show Trial of the Gang of Four.
Well, this was our group at least, and I hope some of it helps with your own. Good luck!
 |
I am currently living in Pittsburgh, PA, working as a Senior Technical Consultant for Summa, and studying as a part-time graduate student in Philosophy at Carnegie Mellon University. | ||
