|
Design patterns are common organization of objects which implement good solutions to frequent programming problems. Patterns are well-tested, reusable, flexible and maintainable solutions that stood the test of time.
Patterns and concept programming address two orthogonal aspects of software: internal organization for patterns, relationship with the application domain for concept programming. If software was music, design pattern would describe the structure of a symphony and what it takes to make it sound good; concept programming would explain how to evoke winter and cold, or a bird singing in a deep forest. Patterns and concept programming complement each other very well.
Patterns as vocabulary
Patterns offer a useful common vocabulary for frequent idioms in the programming community. For that reason, patterns themselves are useful for concept programming.
Consider for instance the "Singleton" pattern, which deals with objects that can exist only in one instance. If the application domain requires a single instance of a given entity, such as the "Window Manager", then this idea is well implemented by a "Singleton" pattern. But the "Singleton" pattern name also conveys the application concept of "there can be only one". In other words, patterns have added "Singleton" to our vocabulary for describing application concepts.
Implementing Patterns
The flip side of the coin is that if you use pattern terminology and concepts, it is certainly a good idea to stick to an implementation which is reasonably close to the original pattern. Concept programming tells us that design patterns that are not recognized as such by the maintainers are not as useful: the "concept" corresponding to the design pattern should be visible in the code.
One easy way to achieve that objective is to use the pattern terminology. This is easy enough for common patterns. It is therefore good practice to name a "there can be only one" entity as "Singleton" and not, say, "Highlander". That is, unless your application really talks about immortals, in which case "Highlander" might convey the concept better.
Patterns can also be recognized by their structure, not just by the name of the elements. You can implement a "Visitor" pattern without having "visit" in any of the names. However, if your objective is for this to be recognized as a Visitor pattern, it might be a good idea to put this in the comments, or to find another way for the pattern to be recognized.
| 