Design Patterns in XML Applications: Part II
by Fabio Arciniegas A.
|
Pages: 1, 2, 3, 4, 5, 6
Advice for the Use and Creation of XML Patterns
A Little Good Advice
|
Table of Contents |
|
•Introduction |
During the use and creation of patterns, several misconceptions and pitfalls can be encountered. Since XML patterns are no exception, I would like to finish by briefly highlighting some of the main trouble spots. For more advice on healthy pattern use, I recommend John Vilissides' book "Pattern Hatching" (see References).
Patterns Are Not the Holy Grail
Patterns are a powerful way to communicate expertise: they create a common design language, they help make your system more understandable to others, etc.... But they are not a replacement for creativity, nor are they automatic quality assurances. Patterns are just another tool in your box—learn them, use them, enjoy them, but don't overestimate them.
Tautologies Are Not Patterns
This phenomenon seems to have cooled down in the traditional pattern world, but it appears to still be a problem in the XML patterns arena. XML "patterns" that merely state a tautology like "use an attribute where an attribute is needed" are not useful for anyone. This problem was pointed out a long time ago by Rick Jelliffe, but still seems common enough to merit mentioning here.
Patterns Are Not Restricted to Particular Aspects of XML Applications
Depending on our personal background, we tend to see some areas as more suitable for pattern creation than others. Some people take this to extremes, claiming XML patterns can only be used in particular situations. This is obviously a mistake. Opportunities to help others gain expertise about recurrent problems and solutions arise in every area. Patterns are a great tool—we don't have to restrain ourselves, let's use them wherever they are useful!
Conclusion
This concludes our brief introduction to XML Patterns. Please write to me (fabio@viaduct.com) if you have questions, suggestions, or want to discuss further work in this field.
