The Concept "Patterns are a recent software engineering problem-solving discipline that emerged from the object-oriented community" "Form of software engineering problem-solving documentation " "A pattern language defines a collection of patterns and the rules to combine them into an architectural style. Pattern languages describe software frameworks or families of related systems. " "Recurring solutions to common problems of design " "A pattern is not an implementation. It describes when, why, and how to go about creating an implementation or other engineering product. " "Problem/Solution pairs in a Context" "Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice”

Pattern Elements Name A meaningful "conceptual handle" for discussion Context Tells how the problem occurs / when the solution works Delineation of situations under which the pattern applies. Often includes background, discussions of why this pattern exists, and evidence for generality. Problem A description of the relevant forces and constraints, and how they interact. In many cases, entries focus almost entirely on problem constraints that a reader has probably never thought about. Design and construction issues sometimes themselves form parts of the constraints. Forces Trade-offs, goals+constraints, motivating factors/concerns Tells why the problem is difficult Solution Tells how to generate the solution The solution structure, its participants & collaborations Examples (optional) Resulting Context (optional) Describes the end result, benefits and consequences Shows how the forces were balanced/traded-off Tells how the solution works out Rationale (optional) Underlying principles/heuristics justifying the solution Tells underpinnings of why the solution works out Related Patterns Patterns which are similar, or which may precede/follow this one Known Uses 3 or more independent instances of "real world" success

Q: What is the relationship between frameworks and design patterns? A: Frameworks are software whereas patterns are knowledge or information about software. Patterns can be used to describe frameworks and some part or aspect of a framework can be a realization of a pattern. Patterns support reuse of software architecture and design they capture static and dynamic structures and collaborations of sucessful solutions to problem that arise when building applications in a particular domain Frameworks support reuse of detailed design and code is an integrated set of components that collaborate to provide a reusable architecture for a family of related applications

Why Patterns? Solve "real world" problems Capture domain expertise Document design decisions and rationale Reuse wisdom and experience of master practitioners Convey expert insight to novices Form a shared vocabulary for problem-solving discussion Show more than just the solution: context (when and where) forces (trade-off alternatives, misfits, goals+constraints) resolution (how and why the solution balances the forces)

Examples Silly example - non programming (local copy) Example use in Java

The Problem Writing good patterns is very difficult. Patterns should not only provide facts (like a reference manual or user's guide), but should also tell a story which captures the experience they are trying to convey. A pattern should help its users to: comprehend existing systems; customize systems to fit user needs; and construct new systems. The process of looking for patterns to document is called pattern mining (or sometimes reverse-architecting). How do you know a pattern when you come across one? The answer is you don't always know. You may jot down the beginnings of some things you think are patterns, but it may turn out that they aren't patterns at all, or they are only pieces of patterns, or simply good principles or rules of thumb that may form part of the rationale of a particular pattern. It is important to remember that a solution in which no forces are present is not a pattern.