How to Access Patterns
Patterns document knowledge that many developers and projects share. If you know a fair number of them, you will be able to find better solutions faster.
To support such a strong claim, take a look at the typical contents of a pattern. While many authors have their individual style and preference, these elements will be there in some form or other:
- A name
- A problem to be solved
- A solution
- Some rationale for the appropriateness of the solution
- Some analysis of the applied solution
The strength of a pattern is not just the solution. It also provides insights on why this is a good solution. And it gives you information not only on the benefits, but also on possible liabilities. A pattern allows you and your peers to make well-informed decisions. It can make all the difference between "this is how it is done" (a stale attitude that prevents new ideas and change) and "this is how and why it is done here" (an attitude that is aware of a world outside of the acquired habits and open to evaluation and learning).
Patterns are useful; the hard part is using them. A problem will come up all of a sudden, and your peers will not wait for someone to claim "I'll find a pattern for this, give me a week to search." You need to have pattern knowledge before you actively consider using one. This is the hard part: Not only does it require lots of work in advance (and patterns often are not the most enjoyable pieces of literature), it also violates how humans often learn — applying some solution, or at least linking the stuff we read, to some experience already present in our brain.
This is why I suggest a three-pass reading style for patterns.
- The name and the first sentence of the solution.
- The problem, the solution, and the consequences.
- Everything, including implementation aspects and examples.
The first pass I do with every pattern I come across. It takes only a few seconds, but you get an impression of what this pattern is all about. Your impression may be off target, but that is OK for now. When some discussion pops up in your project, you will remember such a pattern and you'll be ready for the second pass. Isn't it a bit late by then? Not necessarily. Before a problem becomes urgent, most projects have some warning time. If you are aware of what is going on around your desk and task, you will be ahead just a bit — and this is sufficient.
The second pass is meant to give you all the ammunition you need in the heat of a design discussion. You will be able to judge proposals, and to propose some pattern yourself — or not to propose it. This will take the team forward. Be careful with the pattern name in this phase. Depending on the team background, the name may not ring any bells. In such cases it is better to just explain the idea of the solution than to focus on its name.
The third pass for when you have decided on some pattern and you need to implement it. If you are like me, you probably won't want to read 30+ pages of some pattern before you are certain it's relevant to you.
The first pass involves a paragraph at most and takes a minute. The second pass requires understanding about two pages and probably around 15 minutes. The third pass requires hours, but this is productive work time.
This work is licensed under a Creative Commons Attribution 3
Back to 97 Things Every Programmer Should Know home page