Patterns in this book
This book will cover Django-specific design and architecture patterns, which would be useful to a Django developer. The upcoming sections will describe how each pattern will be presented.
Pattern name
The heading is the pattern name. If it is a well-known pattern, the commonly used name is used; otherwise, a terse, self-descriptive name has been chosen. Names are important, as they help in building the pattern vocabulary. All patterns will have the following parts:
Problem: This briefly mentions the problem.
Solution: This summarizes the proposed solution(s).
Problem Details: This elaborates the context of the problem and possibly gives an example.
Solution Details: This explains the solution(s) in general terms and provides a sample Django implementation.
Criticism of Patterns
Despite their near universal usage, Patterns have their share of criticism too. The most common arguments against them are as follows:
- Patterns compensate for the missing language features: Peter Norvig found that 16 of the 23 patterns in Design Patterns were 'invisible or simpler' in Lisp. Considering Python's introspective facilities and first-class functions, this might as well be the case for Python too.
- Patterns repeat best practices: Many patterns are essentially formalizations of best practices such as separation of concerns and could seem redundant.
- Patterns can lead to over-engineering: Implementing the pattern might be less efficient and excessive compared to a simpler solution.
How to use Patterns
While some of the previous criticisms are quite valid, they are based on how patterns are misused. Here is some advice that can help you understand how best to use design patterns:
- Don't implement a pattern if your language supports a direct solution
- Don't try to retro-fit everything in terms of patterns
- Use a pattern only if it is the most elegant solution in your context
- Don't be afraid to create new patterns
