Matt Deiters gave a few of us a preliminary presentation of his Patterns talk for Tuesday. I'm excited to see him talk, he's one of the most passionate people I've met in the industry, and he's always excited to share his knowledge. Considering his drive and relative age, I consider him my own “John Tukey“. :)
I know there are many of us that initially look at patterns and roll our eyes, knowing that what we do just works... nothing to fix. Patterns are an idealistic waste of time, etc... then we pick up a book, or see a demo, or talk to the right person at the right time, and it clicks...
... “that, what you're doing right there, is exactly what I did that one time to fix that one thing” - well man, there's a name for it. One of us at the talk yesterday bonked himself on the forehead (seriously... really hard even)... I saw the click with him - he had used the Strategy Pattern to solve a problem. The click I'm sure was 2-fold: 1. He solved a programming problem using his own innovation and just found out it was a best practice, and 2. there was a name for it. He's a better coder than he gives himself credit for...
Patterns rule, but if you're reading a book and learning patterns from the top-down, while coding from the bottom-up, it can be difficult to understand how to make them work for you:
1. You need to understand oop. Polymorphism, Inheritence, Interfaces, Delegates... If you're not quite there, there is not a doubt in my mind that mastering these things will make a HUGE difference in your code, and understanding of patterns.
2. You can work toward patterns after your application is coded. When looking at your code, you recognize “smells” - even the rookie programmer smells bad code. You need to know enough about patterns to understand how bad smells in your code like huge methods, duplicated code, and confusing conditionals can utilize them. Refactoring to or toward patterns becomes part of the development cycle.
3. You need to understand the ideas behind each pattern, don't worry about the details until your “just in time“ moment, when you can set it against a context.
4. Remember how you used the pattern to solve the problem. After 3 or 4 implementations, they become second nature.
The funniest thing I'm seeing is the correlation between experienced programmers and their reluctance to consider patterns. Dino tried to jump on the bandwagon not too long ago, and realized he'd been riding it all along... [link] These are the guys with the influence, that need to adopt the science behind it and make it part of the .Net world. Our INETA UG has a few of these guys. I hope they bring their positive energy Tuesday so Matt's first presentation is a good one.
Check out the Agile Developer's weblog here, and come to the WI-NUG meeting Tuesday May 10 for pizza, swag, and a great presentation on patterns in .Net.
| posted on Wednesday, May 04, 2005 4:29 PM