A design pattern can be characterized as “a three-part rule which expresses a relation between a certain context, a problem, and a solution” [Ale79] For software design, context allows the reader to understand the environment in which the problem resides and what solution might be appropriate within that environment. A set of requirements, including limitations and constraints, acts as a system of forces that influences how the problem can be interpreted within its context and how the solution can be effectively applied.
The idea of a pattern is in knowing that you’ve seen a similar problem before. By identifying similar problems, you can know where to start to find a similar solution.
Patterns themselves may not be sufficient to develop a complete design. In some cases it may be necessary to provide an implementation-specific skeletal infrastructure, called a framework, for design work. That is, you can select a “reusable mini-architecture that provides the generic structure and behavior for a family of software abstractions, along with a context … which specifies their collaboration and use within a given domain” [Amb98].
The framework is not a pattern, but a skeleton of with fill in the blank areas to make it more complete. They tend to be more specific that a pattern, focusing on a platform implementation rather than a generic design idea.
A framework will often be a collection of pattern ideas, and thus more complex, allowing you to do more, faster.
Rest of the Chapter
The rest of the chapter goes through describing several different types of patters from high level, component level, and even different types of UI design patterns. Review to be knowledgeable about all the different types of information you might need to know about.
Pattern-Based Design was originally found on Access 2 Learn
