In this section, I do a humble attempt to describe some techniques that worked for me in some of the projects I have used. Mind you that they are not nearly as useful as some of the GoF patterns. Their usefulness is much less broad but the idea is to firstly document them and secondly hope that somebody finds them useful First there is one thing to clarify : Allthough without any doubt, the GoF book is the most popular Design pattern book, there are many other pattern languages than the classical 23 design patterns. There are patterns convering team work, concurrent programming, database programming, analysis, .... The pattern definition is so broad that there are a lot more opportunities for patterns than most people know. Here is the definition of a pattern : A pattern is a named proven solution to a problem in a context. Therefore a pattern is never wrong. It is only more or less applicable to a certain problems.
Patterns encapsulate a set of expertise. The idea is that it provides a means to learn people to reuse them instead of reiventing the wheel. My personal experience leads me to think that this is not entirely correct. You must have had a minimal exposure to real-worl programs to grasp certain patterns. I guess that’s why some people can’t be enthuisatic about patterns. They read it and say “ok, so what ?”. This reaction is typical for some-one who has not been-there-done-that. If you have struggled with the forces of a pattern yourself then you can get a real “aha!” by reading the pattern. If not it will be “oh?” at best.
| |||||||||||||||||||||||||||||||||||||||||||||||||||
Subitems : | |||||||||||||||||||||||||||||||||||||||||||||||||||
[Form As Function] | |||||||||||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||||||||||
| Site updated : Monday, February 17, 2003
| |||||||||||||||||||||||||||||||||||||||||||||||||||
|
| |||||||||||||||||||||||||||||||||||||||||||||||||||